A three-of-five multisig treasury sounds like a well-designed security model — no single signer can authorize a transaction, key compromise requires coordinating three separate signers, threshold chosen deliberately. In practice, multi-chain treasury operations turn this clean model into a coordination problem that's harder than most teams expect when they set it up.
The difficulty compounds with each additional chain. A treasury operating across Solana, Base, and Arbitrum does not have one multisig workflow. It has three separate multisig implementations — the EVM chains use different Safe deployments with different chain-specific addresses, Solana uses a fundamentally different multisig primitive (Squads Protocol or a custom program). Each chain requires its own set of signers, its own quorum logic, its own transaction construction and relay mechanism. When a payment needs to go out on Arbitrum today, you are not asking signers to "approve the treasury transaction." You are asking them to approve a specific Safe transaction hash on a specific chain ID, verify the calldata decodes to the expected operation, and submit their signature via a relay that correctly identifies the Safe address and nonce.
Safe (EVM) multisig mechanics that trip up treasury ops
Safe (formerly Gnosis Safe) is the dominant EVM multisig for treasury operations. The core mechanics are well-understood but the multi-chain deployment specifics are where mistakes happen.
Each Safe deployment is chain-specific. A Safe deployed on Base at address 0xABCD...1234 is a completely different contract than a Safe at the same address on Arbitrum One — even if the deterministic deployment via the Safe factory yields the same address, the two contracts have separate storage, separate nonces, and separate ownership state. A signature produced by a signer for the Base Safe is not valid for the Arbitrum Safe, even if both Safes have identical signer configurations.
The Safe transaction hash includes the chain ID as part of its EIP-712 domain separator. This is the correct design — it prevents signatures from one chain's Safe being replayed on another. It also means that when you send a signing request to co-signers, you must specify which chain's Safe the request is for, and co-signers must verify the chain ID in the EIP-712 domain before approving. The most common treasury ops mistake is a co-signer approving a Safe transaction hash without checking whether the domain separator's chain ID matches the chain they believe they're signing for.
Nonce management across chains
Each Safe has an independent nonce that increments with every executed transaction. On Arbitrum, your Safe might be at nonce 47; on Base, it might be at nonce 23. If two pending transactions are queued on the same chain simultaneously, they must be executed in nonce order. This is fine in isolation but becomes a coordination headache when you have pending operations on multiple chains and signers are approving transactions across all three simultaneously.
A transaction that expires or is cancelled consumes a nonce slot, requiring the next pending transaction to be re-created with the new nonce. In a high-frequency treasury that processes multiple weekly operations across chains, nonce collisions and stale signature sets are a regular source of failed or delayed operations. The mitigation is simple but requires discipline: maintain a clear log of current nonce state per chain, never queue more than one non-dependent transaction per chain at a time, and expire stale pending transactions promptly before they accumulate.
Hardware wallet co-signer setup for multisig
Using Ledger hardware wallets as co-signers in a Safe adds a meaningful security layer but requires correct configuration at setup time. The Ledger's Ethereum app needs to be on a version that supports EIP-712 structured data display — otherwise Safe transaction signing falls back to hash-only display, which is blind signing regardless of the Safe's interface showing a decoded preview.
The derivation path matters. A signer using path m/44'/60'/0'/0/0 on their Ledger will produce a different address than one using m/44'/60'/0'/0 (the legacy path used by some older versions of the Ledger live application). If the Safe was configured with the address derived from one path and the signer's client is submitting signatures from a different path, the signatures will be from the wrong address and will not count toward threshold. This sounds obvious but is a genuine source of confusion in teams where different signers set up their devices at different times with different software versions.
For Solana multisig with Squads Protocol, the hardware wallet integration is different again — Solana uses a different key derivation scheme (m/44'/501'/0'/0' by default for Solana Ledger app), and the Squads transaction display on the Ledger screen depends on the Solana app version and the transaction's program instruction format. Verify the instruction decode before confirming, regardless of what the Squads web interface shows you.
Threshold selection and the coordination trap
Threshold selection is a security-versus-operability tradeoff that most teams make once, at setup, and then live with permanently. A 3-of-5 threshold sounds balanced, but it means you need three signers online and responsive for every treasury operation. If one signer is unavailable for a week, you still have a quorum — but if two are simultaneously unavailable, you're either waiting or making an emergency decision about key recovery.
We're not saying high thresholds are wrong — they clearly provide better security for high-value operations. The issue is that teams often set the same threshold across all chains regardless of the value at risk per chain. A Solana Squads multisig holding protocol liquidity provider positions worth seven figures may warrant a 4-of-6 threshold. A Base Safe used for minor operational expenses might be adequately protected at 2-of-3, allowing faster execution without the coordination overhead of a higher threshold.
Operating with differentiated thresholds per chain and per value tier is more complex to maintain but better reflects the actual risk profile. The key is documenting the threshold logic clearly so all signers understand why a given Safe has the threshold it does and what the process is for threshold changes if circumstances change.
The sign-and-relay flow and where it fails
In a Safe operation on Base, the typical flow is: proposer constructs the transaction in the Safe UI or via the Safe API, co-signers receive a notification, co-signers review and sign on their hardware wallets, once threshold is reached the final signer (or a relay) calls execTransaction on the Safe contract with the collected signatures. The relay step is where operational failures cluster.
The execTransaction call requires the signatures to be ordered by signer address (ascending). If the client assembles them in a different order, the transaction reverts with a signature validation error. The Safe SDK handles this correctly, but custom integrations or manual signature assembly often do not. The result is a wasted L2 gas payment and the need to re-assemble and resubmit.
For cross-chain treasury operations — for instance, a payment that requires a simultaneous action on Arbitrum and Solana as part of a rebalancing — there is no atomic cross-chain execution primitive available today. You are scheduling and coordinating two independent multisig transactions, accepting that they will execute at different block times on different chains. The coordination protocol needs to specify what happens if one executes and the other fails: which is the canonical state, who is responsible for the rollback operation, and what the acceptable window is for the second transaction to complete before the first is considered a problem.
Common operational mistakes and how to avoid them
- Signing without decoding calldata. Co-signers who approve Safe transactions by trusting the UI description rather than verifying the decoded calldata on their hardware wallet are blind-signing. The UI can show "transfer 1000 USDC to operations wallet" while the actual calldata sends to a different address. Verify on the device, not on the screen.
- Storing Safe configuration off-chain without version control. Safe address, chain ID, threshold, owner list, and current nonce state should be in a version-controlled document that all signers can access independently of the Safe UI. If the Safe UI is unreachable, you need to be able to construct and submit transactions manually via the Safe API or directly via contract calls.
- Not verifying the Safe address before signing. The EIP-712 domain separator for Safe signing includes the
verifyingContractfield — the Safe address. Signers should verify this matches the known Safe address for the chain in question before approving. A phishing request using a different Safe address passes all UI validation checks but routes funds to an attacker-controlled contract. - Ignoring gas sponsorship assumptions. On L2 chains, the relayer calling
execTransactionpays the gas. If your assumed relayer is unavailable and the Safe transaction is time-sensitive, you need a fallback relayer configured in advance, not sourced urgently under time pressure.
Multi-chain treasury operations are a solved problem in the sense that the protocols and tooling exist to do this correctly. Where teams fail is in treating it as purely a signing problem rather than a coordination and verification problem. The hardware wallet confirmation is the last step. Correct operation requires that everything before it — transaction construction, chain ID verification, calldata review, nonce management — has already been done correctly by the time you're pressing the button on the device.