@klappay/arc-splits

MIT. A thin viem-based client for the klap-arc fork of 0xSplits' contracts, deliberately shaped close to @0xsplits/splits-sdk's own call surface so swapping to the real package later (see the repo root's docs/migration.md) touches as little consumer code as possible.

Scoped deliberately narrow: only the deterministic-salt create/predict flow (createSplitDeterministic/predictDeterministicAddress(salt)), not 0xSplits' nonce-based createSplit/predictDeterministicAddress() overload — the whole point of this package is the lazy, address-known-in-advance pattern klap-core already relies on with real 0xSplits, so that's the only flow worth wrapping here.

Usage

import { createPublicClient, createWalletClient, http } from "viem";
import { ARC_MAINNET_CHAIN_ID, createArcSplitsClient } from "@klappay/arc-splits";

const publicClient = createPublicClient({ transport: http("https://rpc.arc.io") });
const walletClient = createWalletClient({ transport: http("https://rpc.arc.io"), account });

const splits = createArcSplitsClient(ARC_MAINNET_CHAIN_ID, publicClient, walletClient);

const split = {
  recipients: [merchantAddress, treasuryAddress],
  allocations: [990_000n, 10_000n],
  totalAllocation: 1_000_000n,
  distributionIncentive: 0,
};

// Predicted off-chain, costs nothing — the counterfactual/lazy address.
const address = await splits.predictSplitAddress(split, ownerAddress, salt);

// Only actually deploys the SplitWalletV2 the first time this is called.
await splits.createSplitDeterministic(split, ownerAddress, creatorAddress, salt);

getChainAddresses (used internally) throws if a chain either has no registry entry, or has one whose addresses are still null — i.e. nothing's been deployed there yet via packages/contracts' deploy script. That's deliberate: this package refuses to silently hand out a placeholder address that doesn't point at a real, deployed factory.