A treasury that signs for itself.

Adding SwapsPro to your Safe#

1. In your Safe, open Apps and choose Add custom Safe App.
2. Paste this exact URL:

   Safe App URL

   Copy

   https://www.swaps.pro/swap

3. Confirm, then open it. There is nothing to connect — the app detects the Safe by itself.

$ curl -s https://www.swaps.pro/manifest.json
{
  "name": "SwapsPro",
  "description": "Swap across chains, send or sweep every token in one confirmation, and place gasless limit orders from your Safe.",
  "iconPath": "icon.svg",
  "safe_apps_permissions": []
}

safe_apps_permissions is empty: SwapsPro asks your Safe for no special permissions. The site's content-security policy allows framing by app.safe.global and its subdomains, and nothing else.

How the connection actually works#

A Safe App gets no injected window.ethereum. The only channel to the Safe is postMessage to the parent frame, which the Safe Apps SDK speaks and which is wrapped into a plain EIP-1193 provider. Two things follow:

• There is nothing to approve. Being open inside the Safe is the authorisation, so connecting is silent and identical on a fresh visit and a session restore.
• Transactions queue, they do not execute. Every eth_sendTransaction SwapsPro sends becomes a proposed Safe transaction that still needs your usual owner threshold. That is the desired behaviour, and it is why a treasury can use these tools at all.
• A Safe lives on one chain. The connector reads the Safe's chain from the handshake and narrows everything to it — the supported set is derived from SwapsPro's own EVM chain list (Ethereum, Base, BNB Chain, Avalanche, Arbitrum and Robinhood Chain), and a Safe on anything else is refused with a message rather than half-working.
• Detection is cheap and silent. The Safe SDK is only loaded when the page is framed and the parent answers a handshake within about a second, so a normal visitor never downloads it and an unrelated embedder simply never sees a Safe.

You can also pair a Safe over WalletConnect rather than opening SwapsPro inside it. Everything below works the same way.

How a multisig signs an order#

A contract account has no private key, so it cannot produce the ECDSA signature an order book verifies with ecrecover. SwapsPro detects a contract wallet by code lookup and switches signing schemes.

SwapsPro prefers eip1271 for contract wallets, because it stays gasless and because a pre-signed order's validity clock runs while owners are still signing — which is how a pre-signed order expires unfilled.

The waiting part#

When a dApp sends eth_signTypedData_v4 to a Safe, the Safe does not answer with a signature. It wraps the payload in a SafeMessage and asks its owners to confirm — the request you see as “SafeMessage · Confirmations (0 of 2)”. Only once the threshold is met does a signature exist: the owners' 65-byte signatures, sorted by signer address and concatenated, which is exactly what the Safe's fallback handler verifies and exactly what CoW's eip1271 scheme wants.

The order book runs that verification at POST time, so an eip1271 order can only be posted once a complete signature exists. For a 3-of-5 that can be minutes or days. SwapsPro handles this by computing the SafeMessage hash itself and polling the Safe Transaction Service for the finished signature independently of the connection that proposed it — a WalletConnect request would otherwise time out long before your owners finish.

Paying a team, or moving a treasury#

Batch Send puts every ERC-20 you select into a single EIP-5792 batch, so your wallet asks for one confirmation instead of one per token. From a Safe, that means one proposed Safe transaction for your owners to review — one signature round instead of twelve.

Every transfer is simulated on a public RPC before submission, and any token whose transfer would revert is dropped and named. That matters more for a treasury than it sounds: a wallet that validates the whole batch will reject all of it because of one transfer-locked scam airdrop, and a treasury address collects a lot of those. Full mechanics are on Tools.

Paying many different recipients is a different job — Batch Send moves many tokens to one address. For recurring many-recipient payouts, deploy a Splits contract and pay it once.

TWAP — selling a position over time#

A TWAP is n equal sell orders, one every t seconds. CoW implements it as a conditional order: your Safe authorises a single on-chain record describing the whole ladder, and CoW's watch-tower polls it every block, cuts the part that is valid right now, and posts that part to the order book under the eip1271 scheme. SwapsPro runs none of that infrastructure.

Wallet requirement#

The two setup transactions#

The first time a Safe creates a TWAP, it must be taught to delegate signature verification for CoW's domain. That is two calls, batched into one Safe transaction, and it changes your Safe's configuration — so it is worth understanding before your owners sign it.

// Both setup calls are addressed to the SAFE ITSELF, in this order:
//
// 1. setFallbackHandler(0x2f55e8b20D0B9FEFA187AA7d00B6Cbe563605bF5)
//    -> installs Safe's ExtensibleFallbackHandler.
//       Guarded by the Safe's own "authorized" modifier, so only the Safe can
//       call it on itself.
//
// 2. setDomainVerifier(<CoW's GPv2Settlement domain separator>,
//                      0xfdaFc9d1902f4e0b84f65F49f244b32b31013b74)
//    -> delegates ERC-1271 verification for CoW's EIP-712 domain to ComposableCoW.
//       Lives on the fallback handler and is "onlySelf", so the Safe reaches it
//       by calling itself and falling through — which is why step 1 must land first.
//
// Both are batched into ONE Safe transaction, so the ordering inside the batch
// guarantees the handler exists before the delegation is attempted.

What they change, concretely#

• Your Safe's fallback handler is replaced. It moves from the default compatibility handler to ExtensibleFallbackHandler, which can delegate ERC-1271 verification per EIP-712 domain. This is a real change to how your Safe answers signature checks — the same contract CoW Swap's own frontend installs.
• One domain is delegated. Only CoW's settlement domain is pointed at ComposableCoW. Every other domain keeps behaving exactly as before.
• It happens once. Both halves are checked independently before anything is proposed — whether the handler is installed, and whether the domain is already delegated — so a Safe that is already set up creates its TWAP with a single transaction and is never asked to repoint its handler for nothing.
• A failed check is not guessed. If the RPC read fails, SwapsPro says it could not check rather than assuming. Guessing “already set up” would produce a TWAP the watch-tower can never sign; guessing the opposite would ask you to change your Safe for no reason.

Timing, for a slow multisig#

The ladder's start time is not baked in when the transaction is built — it is written at execution time from the block timestamp. For a 3-of-5 that may take days to collect signatures, this is the difference between a working TWAP and a broken one: a hard-coded start in the past would mean every part whose window elapsed while owners were signing is simply gone, and the ladder would start mid-way and sell less than you asked for.

The three sentences your owners should read first#

One practical consequence for a multisig: cancelling needs your threshold too. If you may want to stop a ladder quickly, size the interval so a cancellation round has time to complete between parts.

Splits — paying a group automatically#

/create deploys audited 0xSplits contracts: an address that shares out every payment it receives, by the percentages you set. For a DAO that is the clean answer to recurring payouts — publish one address, and contributors, a grants program or a revenue share are handled by the contract rather than by a monthly batch of transfers.

What actually happens when you deploy#

1. The chain is switched if your wallet is elsewhere.
2. The deploy is simulated first with eth_call. If it would revert you are told why, in plain language, and never asked to sign it.
3. The factory call — plus the optional support transfer, if you left it non-zero — is sent as one EIP-5792 batch. Wallets without batching send the deploy first and the support transfer separately, and a declined support transfer does not affect the deploy.
4. The new contract's address is read back from the factory's creation event, and the configuration is saved in your browser.

Deploying the same split across several chains in one flow is planned, not built — today it is one deploy per chain, at separate addresses. See Free and Pro.

Everything else#

• Tools — Batch Send and Batch Swap in full, limit orders, the Danger Zone.
• Fees — one table, every path.
• SDK — if your DAO's own front end wants SwapsPro's routing behind it.