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

Where the modules-and-guards question is about what one Safe can do, this one is about how many Safes you actually have. A treasury that "uses Safe" almost never uses a Safe — it runs deployments on Ethereum, Arbitrum, Base, Optimism, and more. They are separate smart contracts, frequently and wrongly assumed to be the same wallet because the address matches. The operational reality is that cross-L2 treasury is a completeness, bridging, and per-chain-finality problem first, and an accounting one only once those are solved. This guide works through that order.

In short

• A Safe is deployed per network — same address does not mean same Safe unless it was deterministically deployed and is still identically configured.
• Owner sets and modules can diverge per chain over time, so verify each chain's Safe separately.
• Cross-L2 treasury is a completeness problem: every Safe on every chain has to be inventoried.
• Cross-L2 transfers are bridge or burn-and-mint events — pair them into one internal movement, not an unrelated outflow and inflow.
• Per-chain finality matters: model the withdrawal-in-progress state and don't double-count in-flight funds.
• Accounting is the output of getting completeness, classification, and finality right — not the starting point.

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 means guaranteed-identical is a dangerous treasury assumption. Verify each chain's Safe configuration separately: owners, threshold, and enabled 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, and 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 have to 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.

Implementation checklist for a multi-chain Safe treasury

The following covers the operational steps required to run a cross-L2 Safe treasury with a clean accounting record:

Inventory and verification:

• Maintain a master register of every Safe address and the chain it is deployed on. The register is a formal document, not a shared spreadsheet with no owner. It includes: chain name, chain ID, Safe address, deployment date, current threshold, current signer list, and enabled modules.
• Each entry in the register is independently verified at least quarterly against the on-chain state — not assumed unchanged. Signer sets and modules on an L2 Safe can be changed by a transaction on that chain; the register must reflect current on-chain state.
• When a new L2 is added to the treasury footprint, the master register is updated before any funds are bridged to it.

Cross-chain movement controls:

• Every cross-L2 fund movement is pre-approved through the same governance path as any other treasury outflow — no bridge transfers outside the documented approval process.
• The bridge or burn-and-mint event is recorded as two legs of a single internal transfer in the accounting subledger: an outflow on the source chain and a corresponding inflow on the destination chain, linked by a common reference ID.
• Bridge fees and gas costs on both legs are captured as separate expense events, not absorbed into the transferred amount.
• A bridge-in-transit log tracks the in-flight period — the window between the source-chain outflow and the destination-chain confirmation. During this window, the amount is held in a "transit" account in the subledger and is not reported as available reserves on either chain.

Finality management:

• For each L2 in the treasury footprint, document the finality model (validity proof, optimistic with challenge period, or other) and the expected time to L1 finality.
• Withdrawal operations are tracked in the same transit log as bridge movements, with the challenge-period expiry date recorded.
• Treasury KPI reporting distinguishes L2-final from L1-final balances, so the board report does not present optimistic-rollup funds as unconditionally available.

Accounting treatment for cross-L2 treasury operations

The multi-chain Safe footprint creates several specific accounting entries beyond standard transaction recording:

• Initial bridge to L2: treated as an internal transfer of treasury funds. No disposal or gain/loss is recognised. Both legs are matched and the bridge fee is an expense.
• Ongoing L2 operations: each L2 Safe is a distinct sub-ledger account. Month-end closing reconciles each chain's sub-ledger balance to the on-chain balance as of a consistent timestamp.
• L2 contract deployment costs: gas spent deploying a Safe on a new L2 is a one-time administrative expense. The deployment creates no asset — the Safe contract holds value but is not itself a balance-sheet asset separate from the assets it holds.
• Modules enabled on a specific chain: the governance cost (gas) of enabling a module on one chain's Safe is an expense event for that period. It does not affect the other chains' Safes.

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.

Choosing a tool for a multi-chain Safe footprint

Most reconciliation tools — Cryptio, Bitwave and others — read Safe activity across networks. The recurring multi-chain error is treating a single cross-chain Safe identity as given, so the questions to ask are specific. Before relying on a consolidated number, confirm the tool:

• inventories Safes per chain as distinct items, rather than collapsing one address into a single global wallet;
• pairs cross-L2 movements as one internal own-fund transfer with fees on both legs, instead of an unexplained outflow and an unrelated inflow;
• handles per-chain finality and the withdrawal-in-progress window, so optimistic-rollup funds in transit are not reported as settled on either side.

A tool that aggregates "the Safe" across chains as one wallet will produce a tidy total that hides exactly the per-chain divergence and in-flight bridging that determine whether the number is real.

How Wag3s handles it

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 — Deploying a Safe Account on multiple chains: the same address is achievable across chains via deterministic (CREATE2) deployment with identical owners/threshold/modules at deployment time, and non-EVM chains (e.g. zkSync Era) cannot use this method — which is why per-chain configuration must be verified rather than assumed.
• Safe — How Safe Smart Accounts work: each Safe is its own contract instance with its own owner set and modules, which can be changed independently on each chain.
• The cross-L2 completeness, paired-transfer (not disposal), and per-chain-finality points are operational treasury practice built on the above, not a single cited page.