Raw Disperse 2.0 ABI exports.
The singleton and subwallet ABIs are the same contracts as the 1.x line, at the same addresses. The ERC-7984 operator fragment is re-exported here because every disperse mode needs the sender's setOperator grant first.
Available ABIs
disperseConfidentialAbi@tokenops/sdk/fhe-disperseDisperseConfidential singleton: register, the three disperse entry points, disclosure, fee config and reserve, batch limits, recovery and AccessControl.
53 fns20 eventsdisperseWalletAbi@tokenops/sdk/fhe-dispersePer-user subwallet clone: holds wallet-mode inflow; its approve, revoke and recover surface is callable only by the singleton.
6 fns1 eventserc7984OperatorAbi@tokenops/sdk/fhe-disperseMinimal ERC-7984 isOperator / setOperator fragment behind setOperator, revokeOperator and the preflight's hasApprovedSingleton read. Also exported from /fhe.
2 fns1 events
Direct viem usage
The SDK client classes are the recommended surface — they handle encryptor resolution, branded ids, retries, telemetry. But the ABIs themselves ship for one-off reads, indexing, or third-party tooling integration.
import { getContract } from "viem";
import { disperseConfidentialAbi } from "@tokenops/sdk/fhe-disperse";
// Attach directly to viem if you'd rather skip the SDK client class —
// useful for one-off reads or for surfacing the contract in your own tooling.
const contract = getContract({
address: contractAddress,
abi: disperseConfidentialAbi,
client: { public: publicClient, wallet: walletClient },
});
// Now you have a viem-typed contract — every method exists on contract.read /
// contract.write. The SDK client class wraps this with retries, encryptor resolution, branded ids —
// but the underlying ABI is the same.