Safe-on-L2 Treasury: One Org, Many Chains, One Set of Books

A treasury that "uses Safe" rarely uses a Safe — it runs Safes on Ethereum, Arbitrum, Base, Optimism, and more. They are separate contracts, sometimes wrongly assumed identical because the address matches. This guide is the cross-L2 treasury problem before it reaches accounting.

TL;DR

• A Safe is deployed per network — same address ≠ same Safe unless deterministically deployed and still identically configured.
• Owner sets / modules can diverge per chain over time — verify each chain's Safe separately.
• Cross-L2 treasury is a completeness problem: every Safe on every chain must be inventoried.
• Cross-L2 transfers = bridge / burn-and-mint — pair into one internal movement, not unrelated out/in.
• Per-chain finality matters — model the withdrawal-in-progress state; don't double-count in-flight funds.
• Accounting is the output of getting completeness + classification + finality right.

Same address is not the same Safe

A Safe is a smart contract deployed per network. The same address on two chains is the "same" Safe only if it was deployed deterministically with identical setup — and even then, the owner set and modules can diverge as each chain's Safe is changed independently over time. Assuming same-address-different-chain = guaranteed-identical is a dangerous treasury assumption. Verify each chain's Safe configuration separately (owners, threshold, modules).

Completeness across L2s

An organisation typically runs multiple Safes across multiple L2s (and L1). A treasury view that covers some chains but not others understates holdings and breaks reconciliation. Each chain's Safe is a separate inventory item. Cross-L2 completeness — every Safe on every chain enumerated — is the precondition before any consolidated treasury number means anything (the multi-chain completeness discipline, applied to Safes).

Cross-L2 movements are paired events

Moving treasury value between L2s is a bridge or burn-and-mint event — not a single transfer. Naive tracking sees an unexplained outflow on chain A and an unrelated inflow on chain B. Cross-L2 treasury movements must be paired into one internal movement of the org's own funds, with fees captured — exactly the cross-chain transfer reconciliation discipline, and never booked as a disposal.

Per-chain finality

On validity or optimistic rollups, a transaction can be usable on the L2 before it is L1-final, and bridged withdrawals lag further. A treasury view that treats an in-flight bridged amount as already settled, or double-counts it across layers during the delay, misstates available funds. Per-chain finality and the withdrawal-in-progress state must be modelled, not assumed instant.

Then, accounting

Only after completeness, paired cross-L2 movements, and finality are handled does the accounting layer produce a clean consolidated result: every Safe on every chain inventoried, cross-L2 own-fund moves as internal transfers, per-chain finality respected, each chain reconciled to the books with an audit trail. Accounting is the output, not the starting point.

Practical guidance

1. Inventory every Safe on every chain — completeness first.
2. Verify each chain's Safe config (owners/threshold/modules) — don't assume same-address-identical.
3. Pair cross-L2 movements into one internal own-funds transfer; capture fees.
4. Model per-chain finality and the withdrawal-in-progress state.
5. Never book cross-L2 own moves as disposals.
6. Reconcile each chain to consolidated books with an audit trail.

How vendor tools handle multi-chain Safe

Cryptio and Bitwave reconcile Safe activity across networks. Confirm the tool inventories Safes per chain (not one assumed address), pairs cross-L2 movements as internal transfers, and handles per-chain finality — assuming a single cross-chain Safe identity is the recurring multi-chain error.

How Wag3s helps

Wag3s Ledger inventories every Safe on every chain as a separate item, verifies per-chain configuration, pairs cross-L2 movements as internal own-fund transfers with fees, respects per-chain finality, and reconciles each chain to consolidated books with an audit trail. See the Ledger product page and the Wag3s for accountants page.

Further reading

• Safe Treasury Setup Best Practices
• Multisig Treasury Reconciliation (Safe)
• Cross-Chain Transfer Reconciliation (CCTP & Bridges)
• zkSync Era Portfolio Tracking
• L2 Accounting: Arbitrum, Optimism, Base
• Multi-Chain Portfolio Aggregation Beyond EVM

Sources

• Safe — deployed per network; the same address across chains is the same Safe only if deterministically deployed and still identically configured (owners/modules can diverge per chain)
• Cross-L2 treasury completeness (every Safe on every chain) and cross-L2 movements as paired internal transfers (bridge/burn-and-mint, fees captured) — not disposals
• Per-chain rollup finality and the withdrawal-in-progress state must be modelled (avoid double-counting in-flight bridged funds)