Add Clasp to your dapp

import { createConfig, http } from "wagmi";
import { claspConnector, xrplevm, xrplevmTestnet } from "clasp-connect/wagmi";

export const config = createConfig({
  chains: [xrplevm, xrplevmTestnet],
  transports: { [xrplevm.id]: http(), [xrplevmTestnet.id]: http() },
  connectors: [claspConnector()],
});

That’s the integration. useConnect, useAccount, useSendTransaction, useWriteContract and useSignTypedData all work against it, and so does SIWE through signMessage.

Reads never reach the connector at all. useBalance, useReadContract and the rest go through config.getClient(), which is built from your chains and transports — so you already own the whole read surface, and the connector’s job is accounts and signing.

The two chain literals ship with the package: xrplevm is 1440000 and xrplevmTestnet is 1449000. Both leave multicall3 undefined on purpose, because it isn’t deployed on XRPL EVM — viem then reads with individual eth_calls instead of batching against a contract that isn’t there.

RainbowKit

import { connectorsForWallets } from "@rainbow-me/rainbowkit";
import { claspWallet } from "clasp-connect/rainbowkit";

const connectors = connectorsForWallets(
  [{ groupName: "Recommended", wallets: [claspWallet] }],
  { appName: "My dapp", projectId: "…" },
);

Three things the config doesn’t show

import { connect, getAccount, reconnect } from "@wagmi/core";

// Page load: restores { address, chainId } from storage. No popup.
await reconnect(config);
const { address } = getAccount(config);

// From a click, and only from a click — this opens the Clasp window.
await connect(config, { connector: config.connectors[0] });

Those are @wagmi/core actions. The React hooks are the same calls with a subscription attached, so the shape holds either way.

XRPL: a whitelist

On the XRP Ledger, Clasp signs two transaction types and nothing else. If the review can’t render a field’s meaning, the request comes back refused — not shown as a hex blob with an Approve button under it. Send anything outside this table and you get a refusal, not a warning.

The structural check lives in one file, sdk/src/protocol.ts, and both the SDK and the popup run it — the popup trusts nothing the SDK claims to have validated. This side stays a whitelist until the XRPL review engine is built. Widening it is a design decision, not a patch.

XRPL EVM: open signing

The EVM side was a two-shape whitelist too, until August 2026. It was opened on purpose: the first lending app we integrated had nine write shapes and the old rule could sign none of them. Clasp now works with the whole XRPL EVM ecosystem the way MetaMask and Rabby do.

The popup signs your exact bytes, and the review is an interpretation of those bytes at the deepest fidelity that settles. Nothing is re-encoded between what the user read and what gets signed.

A call that carries XRP alongside its calldata is legal at every tier, and the XRP rides as its own row on the review.

Two rules that shape how your dapp behaves

Messages and typed data

A message signature follows the same idea. Clean UTF-8 renders as text; bytes that aren’t valid UTF-8, or that hide control or bidi characters, render as the exact hex behind a warning — the hex is what gets signed, so showing it whole is the honest review, and unreadable is never a refusal. Messages cap at 8 KiB. Typed data renders as a field tree, and a domain naming a chain the user isn’t connected to warns rather than blocks.

The two things Clasp still refuses

Opening the tier ladder didn’t mean everything signs. Two refusals survive on the EVM side, and neither of them is about calldata. A method Clasp simply doesn’t implement is a different thing — the reference below says what’s on the wire, and the connector answers the rest by naming the method that replaces it.

evm_sign_and_submit resolves the moment the transaction is broadcast, carrying its hash — the contract every EVM wallet keeps, and what lets you chain a second write off your own receipt wait. The popup keeps confirming after you already have the hash, because the Seal it presses is about finality and the response is not. A revert after broadcast reaches you the way it does with any other wallet: through the receipt.

The local answers matter more than they look. viem asks for the chain id before every signing operation, and answering that from memory is what keeps your click alive for the window that opens right after it. The forwarded ones are compatibility, not the normal path — wagmi’s own reads go through config.transports, and these fifteen exist for code that takes the provider directly. Note that they leave from your page, so your CSP governs the fetch, not ours. And eth_sign is refused on purpose: it is blind signing, and it is one of the two things Clasp will not do on this chain. §05 has the other one, and what the review shows instead.