# Splits Splits is financial infrastructure for onchain builders and startups. Splits Treasury and Splits Personal are self-custodied multichain account products that combine banking operations (payroll, vendor payments, bank transfers, accounting) with programmable custody (multi-sig by default, passkey authentication, programmable recovery). Splits also maintains an open-source contract suite (Split, Waterfall, Swapper) that powers onchain payment flows. ## Products ### Splits Treasury: Business banking for onchain startups - [Product page](https://splits.org/treasury) - [App](https://app.splits.org/) — sign in or register, no paperwork - [Guidebook](https://splits.notion.site/guidebook) Self-custodied multichain accounts with passkey auth and multi-sig by default. Configurable approval thresholds, subaccounts per revenue stream or project, automated token swaps on receipt, payroll, recurring vendor payments, bank transfers, fiat on/offramps, integrated yield, accounting exports, and read-only accountant access. ### Splits Personal: A wallet purpose-built for builders - [Product page](https://splits.org/personal) - [App](https://app.splits.org/) — sign in or register, no paperwork - [Guidebook](https://splits.notion.site/guidebook) Self-custodied multichain wallets with passkey auth and multi-sig by default. Configurable approval thresholds, programmable recovery (hardware wallets, trusted contacts, timelocked backups), subaccounts, bank transfers, and fiat on/offramps. ## Security model Every Splits account is a SmartVault: an audited ERC-4337 smart account (EntryPoint v0.7) deployed as a UUPS proxy, based on Coinbase's Smart Wallet. Source and audits: https://github.com/0xSplits/splits-contracts-monorepo (packages/smart-vaults). Deployed factory addresses per chain are in packages/smart-vaults/deployments/. **Two layers of onchain control.** Every account has an owner and a signer set, and the owner outranks the signers: it can execute from the account directly and upgrade its implementation (upgrades are owner-only — no threshold of an account's own signers can reach the upgrade path, even via a self-call), and no threshold of the account's own signatures can modify, remove, or bypass the owner. Signers authorize transactions: passkeys and EOAs are equal-power signers counted against one m-of-n threshold, with no distinction by operation type and no per-signer scoping by target or function. Accounts form an ownership chain, fixed at creation and identical on every EVM network (addresses are CREATE2-deterministic): the org's root account sits at the top with no owner, controlled by your recovery wallets as its m-of-n signer set (1-of-1, 2-of-3, 3-of-5, or custom); the root owns the treasury account, and the treasury owns each subaccount. Each level's signers transact; the owner one level up recovers — treasury signers rotate subaccount signers, and the root resets treasury signers. The root has no owner to appeal to: its signer set is rotated only by its own threshold, making the recovery wallets the org's ultimate root of trust. **What a compromised signer key can and cannot do.** A key that meets a subaccount's threshold can take any action from that subaccount — including changing its signer set — via UserOps submitted directly to a bundler, without the Splits API (web-only approval flows are platform policy, not chain enforcement). It can never touch the owner. Recovery is contract-enforced: the parent account, as owner, rotates the subaccount's signers back, bypassing its threshold entirely — an ordinary owner call, executable as plain transactions via any RPC; the web app surfaces it but is not a dependency. Blast radius of a leaked signer key = the subaccount's contents and actions taken before the parent rotates it; the subaccount's address survives, so anything pointing at it (deposits, integrations, delegations) never needs to change. **Sizing agent access.** Give an agent its own subaccount holding only what it needs. Threshold 1 lets it act alone within that blast radius; threshold ≥ 2 keeps a human co-signature on every action. Per-signer restrictions by target contract or function do not exist onchain today. **Gas and liveness.** New orgs start with sponsored gas — UserOp fees are covered up to a budgeted org-level sponsorship policy; beyond it, accounts pay their own UserOp gas from their balance. Refunds and incoming funds accrue to the account. Signing keys live with signers, not with Splits — if the Splits API is unreachable, a signer can construct and submit UserOps directly to any public bundler using standard ERC-4337 tooling (the CLI does not automate this). ## Agent access The CLI is the primary programmatic entry point. It ships with a built-in MCP server exposing the same surface, so anything a human can do in the app, an agent can do through the CLI or MCP. - npm: https://www.npmjs.com/package/@splits/splits-cli - Full command surface without installing: `npx -y @splits/splits-cli@latest --llms-full` - Install: `npm install -g @splits/splits-cli` ### Bootstrap as a signer To act on a human's account, you (the agent) need your own key registered as a signer on their account. Steps: 1. The human creates an API key at https://app.splits.org/settings/team/api-keys/ and provides it to you. This step is browser-only — there is no programmatic route. 2. Run `splits auth login` with that key. 3. Run `splits auth create-key --register` to generate your EOA and register it as a signer candidate. The command returns your signer id. 4. Give the signer id to the human. They run `splits accounts update-signers --addEoaSignerIds `, which creates a proposal and returns a `signUrl`. The human opens the URL and approves in the web app. 5. Once approved, you can sign transactions with your own key, subject to whatever thresholds and policies the human configured. See `npx -y @splits/splits-cli@latest --llms-full` for the full command surface, flags, and MCP tool list. ### Create a new account with both signers Alternative to "Bootstrap as a signer". Instead of joining an existing account, create a new subaccount with you and the human as signers from the start. The web-approval step disappears — the subaccount is born with the right signer set, so no proposal or `signUrl` is involved. Prerequisites: steps 1–3 above (human-minted API key, `auth login`, your EOA registered via `auth create-key --register`). 1. Find the human's user id: `splits members list`. 2. Find the human's passkey signer id: `splits members signers `. 3. Create the subaccount: `splits accounts create --name "