Unified Treasuries: Managing Your frfr.fun DAO Assets Across Base, Solana, and Arbitrum

When a token graduates from its initial bonding curve on frfr.fun, a crucial operational challenge emerges for its Decentralized Autonomous Organization (DAO): capital management. Successful launches often begin on Base — leveraging its low gas fees and native USDC settlement — but as trading volume expands, some communities look to deploy liquidity, fund growth bounties, and build presence across other ecosystems like Solana and Arbitrum.

Traditionally, this has meant maintaining separate multisig wallets on every target chain: fragmented signer sets, disconnected governance interfaces, and the operational risk that comes with proliferating seed phrases and approval flows.

This piece lays out how a DAO treasury can be structured across multiple chains using today's actual tooling — Safe (formerly Gnosis Safe) on the EVM side and Squads on Solana — what a "unified" setup really looks like in practice, and, importantly, where the security trade-offs are sharpest. Some of the architecture below is illustrative rather than a description of a single off-the-shelf product, and that distinction is called out explicitly where it matters.

1. The Multi-Chain Expansion Trap

Graduating off a bonding-curve launchpad is a milestone. frfr.fun states that a percentage of bonding-curve trading volume accrues to creators as a fee, paid in USDC; the exact figure and mechanics are a platform-specific claim that this article can't independently verify and readers should confirm directly against frfr.fun's own documentation before relying on it for financial planning.

As an operational treasury grows, community proposals tend to move from simple marketing spend toward multi-chain liquidity provisioning. Moving capital across ecosystems introduces real friction:

Multisig fragmentation. Running a Safe on Base, a separate Safe on Arbitrum, and a Squads multisig on Solana means tracking different signer sets and thresholds across disconnected interfaces.
Signer latency. Getting a 3-of-5 or 4-of-7 signer set to approve a routine rebalance on one chain is already a coordination task. Repeating that across three chains multiplies the friction and the chance a time-sensitive proposal stalls.
Bridge and module risk. Moving assets across chains generally means either wrapping tokens through a lock-and-mint bridge or granting a smart-contract module delegated authority to act on the treasury's behalf. Both introduce a new trust boundary — and both have caused real losses (more on this in Section 5).
Accounting fragmentation. Tracking spend across multiple chain explorers with different fee structures makes financial reporting harder for community managers and, increasingly, for anyone trying to stay ahead of regulatory disclosure expectations.

Scaling a DAO treasury across chains is less about finding one silver-bullet protocol and more about deliberately trading off convenience against the number of new trust assumptions each cross-chain hop introduces.

2. The Real Building Blocks: Safe on EVM Chains, Squads on Solana

It's worth being precise about what exists today, because the marketing language around "unified cross-chain treasuries" often blurs two genuinely different things: a shared governance process across chains, versus a single technical system that directly controls assets on every chain from one root account.

Safe (the protocol formerly known as Gnosis Safe, rewritten in 2018 and rebranded in 2022) is the dominant smart-contract treasury wallet on EVM chains, and secures tens of billions of dollars across more than a dozen EVM networks. Its architecture separates a Singleton contract (the shared logic) from lightweight Proxy deployments (one per Safe), with optional Modules and Guards that extend or constrain what the Safe can do.

Safe{Core} Protocol is a separate, more experimental framework layered on top of this: an open, modular system whose stated building blocks are the Manager (coordinates Accounts and Modules), the Registry (vets which Modules are trusted), and Modules themselves — which in Safe{Core}'s own documentation are scoped as Plugins, Hooks, Function Handlers, and Signature Verifiers. It is worth noting this doesn't map cleanly onto "an Arbitrum Module, a Solana Adapter, and a Polygon Module" as a documented, off-the-shelf product suite. Cross-chain remote-execution setups for Safe do exist (for example, third-party projects that let a "Controller Safe" on one chain execute transactions on a "Secondary Safe" on another chain via block-header relays), but these are separately built and audited integrations, not a native Safe{Core} feature you toggle on.

Squads is Solana's dominant multisig and smart-account protocol, not an EVM-compatible system and not a "module" that plugs into Safe. It runs entirely on Solana, is formally verified, and by 2026 has been used to secure over $10 billion in assets — including roughly $3 billion in stablecoins — across 300+ teams such as Jito, Drift, and Pyth. The current Squads V4 release adds time locks, per-member spending limits, granular roles (Proposer/Approver/Executor), sub-accounts for departmental treasury separation, and batch transactions. Squads is comparable to Safe in what it lets a DAO do operationally, but the two are independent systems that don't share a signer set or a root account.

So the practical picture for a frfr.fun DAO is closer to: one Safe on Base as the home treasury, a separate Safe (or a remote-execution module controlled by the Base Safe) on Arbitrum, and an entirely independent Squads multisig on Solana, coordinated by policy and cross-chain messaging rather than unified under one literal contract.

3. Cross-Chain Coordination: What Actually Moves the Message

Whatever pattern a DAO chooses for extending governance authority across chains, the messages themselves have to travel over an actual interoperability protocol. As of 2026 there are a handful of protocols doing the bulk of this work, each with different trust assumptions:

Chainlink CCIP verifies and delivers messages through Chainlink's decentralized oracle network (DON) infrastructure, with separate committing and executing node sets, and underpins the Cross-Chain Token (CCT) standard for making a token natively cross-chain-transferable without wrapping.
Wormhole uses a fixed set of 19 professional Guardian node operators who sign a Verified Action Approval (VAA) once 13 of 19 agree a message is valid. It has the broadest non-EVM coverage of the major messaging protocols (Solana, Sui, Aptos, and Cosmos chains via IBC), supporting 30+ chains and having processed over a billion cross-chain messages to date. Its guardian set is not static, however — Wormhole fully deprecated support for Scroll in April 2026, and Moonbeam is scheduled to shut down entirely on July 31, 2026, with GLMR migrating to Base.
LayerZero v2 takes a more configurable approach: each application picks its own set of Decentralized Verifier Networks (DVNs) rather than inheriting one fixed trust model. It has the widest chain coverage of the general-purpose messaging protocols (90+ chains as of 2026) and currently carries the largest share of retail bridge volume.
Circle's CCTP (Cross-Chain Transfer Protocol) is narrower by design but arguably the most relevant option for a USDC-denominated treasury like frfr.fun's: rather than wrapping USDC, it burns the token on the source chain and mints native USDC on the destination chain, attested by Circle's own signing service, typically settling in under 20 seconds on fast-finality chains. The trust model is centralized in Circle, which is a reasonable trade-off for an asset Circle already issues and controls. Circle also closed its acquisition of Interop Labs (the team behind Axelar's IP) in early 2026, signaling further consolidation of stablecoin-specific cross-chain rails under Circle.

For a frfr.fun DAO whose treasury is USDC-denominated on Base, CCTP is likely the most operationally direct way to move the stablecoin itself to Arbitrum (both are CCTP-supported chains) without taking on wrapped-asset risk. Wormhole or LayerZero become more relevant when the DAO needs to pass governance instructions (not just USDC) to a non-EVM chain like Solana, or when it wants to move a non-USDC asset.

One correction worth flagging on the sourcing side: earlier drafts of this kind of piece sometimes cite "Wormhole or Pyth" interchangeably as cross-chain bridge options. Pyth Network is an oracle — a price-feed network, not a bridge or general message-passing protocol. Pyth does use Wormhole's Guardian network internally to distribute its price data from Pythnet to 40+ consuming chains, but it isn't itself a mechanism a DAO would use to relay treasury instructions or move assets. Any Safe or Squads setup that needs live pricing (for a rebalancing bot, say) might reasonably integrate Pyth or Chainlink Data Feeds as an oracle, but that's a different job from the cross-chain messaging layer.

4. Handling Solana Specifically

Because Solana's SVM runtime can't natively parse EVM state, coordinating a Base treasury with Solana activity requires an explicit bridge between the two governance systems — there's no way around a translation layer:

Signers approve on Base, as with any other treasury action.
A relayer or messaging protocol (Wormhole's NTT/VAA framework is the most Solana-native option; CCTP works if the payload is specifically USDC) carries the instruction or the attested value to Solana.
The Squads multisig on Solana executes independently, using its own signer threshold — which in practice usually means either mirroring the Base Safe's signer set as Squads members directly, or having a small subset of trusted signers/automation execute pre-approved, capped actions once the cross-chain message lands.

This is meaningfully different from "the Base Safe controls the Solana multisig." It's closer to two independently governed treasuries kept in sync by policy, messaging, and (ideally) overlapping human signers — which is a more honest description of what's achievable today than a single root account with remote puppet accounts on every chain.

5. Security & Risk: What's Actually Gone Wrong

Consolidating treasury operations increases efficiency but concentrates risk, and 2026 has already produced a concrete illustration of why "modules that extend a Safe's authority across boundaries" deserve real scrutiny rather than being treated as a solved problem.

The Squid module exploit (May 2026). Blockaid identified an exploit affecting 86 Gnosis Safe wallets across Ethereum and Base, draining roughly $3 million. The attacker exploited a vulnerability in a contract called "SquidRouterModule" — a module tied to the cross-chain protocol Squid — that let malicious transactions impersonate authorized delegates and execute arbitrary token swaps from victim Safes. Squid publicly stated its core contracts and users were not affected and distanced itself from the vulnerable module, but the incident is a live example of the exact risk this article's Section 2 diagram gestures at: a module with delegated authority over a Safe is only as trustworthy as that module's own code, independent of how well-audited the base Safe contracts are.

More broadly, cross-chain bridges accounted for roughly 40% of all Web3 exploit value in 2025, with cumulative bridge-hack losses estimated around $2.8 billion. That's the base rate a DAO treasury committee should have in mind before wiring meaningful capital through any bridge or cross-chain module, however reputable.

With that context, sensible controls for a multi-chain frfr.fun treasury include:

Granular role-based access. Not every payment needs full signer-set consensus. Both Safe (via Modules/Guards) and Squads V4 (via its native Roles and Spending Limits features) support delegating small, capped, pre-authorized actions — e.g., a weekly marketing allowance — without exposing the full treasury to a lower-trust signer or automation.

Timelocks on cross-chain instructions. A mandatory delay window between a cross-chain instruction being signed and it being executable gives the DAO time to catch and pause a compromised or mistaken transaction before funds move. This is standard practice in professional onchain treasury operations, not a frfr.fun-specific innovation.

Treat bridge exposure as a risk budget, not invisible plumbing. A treasury that looks diversified by token symbol can still be dangerously concentrated if every position ultimately depends on the same messaging protocol or guardian set. Spreading cross-chain rails (e.g., using CCTP for USDC specifically, rather than routing everything through one general-purpose bridge) reduces single-point-of-failure exposure.

Independent, ongoing monitoring. Treasury security doesn't end once permissions are configured. Professional onchain treasury operators (firms like Karpatkey and Avantgarde manage DAO treasuries under defined mandates; Den, Steakhouse Financial, and Llama provide onchain reporting) build continuous monitoring for large transfers, role changes, module enablements, and unusual approval patterns — because incidents like the 2022 Ronin bridge hack went undetected for days precisely because nobody was watching after setup.

6. Regulatory Context

Any DAO treasury operating across jurisdictions and asset types should be tracking the shifting U.S. regulatory picture, which has moved substantially in the past year. The SEC and CFTC published a joint five-category token taxonomy on March 17, 2026, intended to clarify which digital assets fall under which agency's jurisdiction. The GENIUS Act, signed into law in July 2025, established a clearer federal framework for dollar-backed stablecoins — relevant directly to a USDC-denominated treasury like frfr.fun's. Separately, the CLARITY Act — which would set broader market-structure rules for digital assets — remains stalled in the Senate, with market odds generally estimated in the 40–50% range for passage. None of this constitutes legal advice, and a DAO moving meaningful capital across chains and into new jurisdictions should get its own counsel rather than relying on a blog post's summary.

7. A Reasonable Operational Starting Point

Rather than presenting a fixed five-step deployment script as if it were a documented product flow, here's a more honest sequencing for a DAO actually building this out:

Deploy the home Safe on Base with your core and community signers, and treat it as the canonical source of truth for treasury policy.
Deploy a Squads multisig on Solana independently, ideally with meaningful signer overlap with the Base Safe, rather than assuming one system can remotely control the other.
Pick cross-chain rails deliberately per use case: CCTP for moving USDC itself between EVM chains that support it; Wormhole's NTT or a comparable messaging protocol when Solana needs to receive governance instructions rather than just USDC.
Scope any delegated module narrowly and audit it independently — the Squid incident above is the cautionary tale for why "it's a module on top of an audited Safe" isn't sufficient reassurance on its own.
Add timelocks, spending caps, and continuous monitoring before, not after, meaningful capital moves through the setup.

8. Looking Ahead

As automated market-making and AI-driven treasury agents become more common in DeFi, well-scoped role-based permissions and spending limits (the kind Squads V4 and Safe Modules/Guards already support) become more important, not less — an agent operating with a capped, auditable mandate is a fundamentally different risk profile than one holding unrestricted signer authority. Multi-chain treasury tooling is still maturing quickly, and DAOs adopting it today should expect the specific protocols and integrations recommended here to keep evolving.

Corrections and Transparency Log

This piece is a substantially rewritten and fact-checked version of an earlier draft. Key changes:

frfr.fun's 6% creator fee claim removed as stated fact. The specific fee percentage is a platform self-description that this article can't independently verify; readers should confirm current terms directly with frfr.fun.
Safe{Core} architecture corrected. The original draft described Safe{Core} as having native "Arbitrum Module," "Solana Adapter," and "Polygon Module" components in a single product suite. Safe{Core}'s own documentation scopes its Modules as Plugins, Hooks, Function Handlers, and Signature Verifiers — a more general framework, not a documented multi-chain remote-execution product. Cross-chain Safe control does exist via separate third-party integrations, which is now stated explicitly.
Squads reframed as an independent protocol, not a Safe{Core} "bridge adapter." Squads runs entirely on Solana and does not plug into Safe{Core} as a module; the two systems are independently governed and coordinated by policy and messaging rather than unified under one contract.
Pyth Network's role corrected. The original draft listed Pyth alongside Wormhole as a "state bridge" option for treasury execution. Pyth is an oracle (price-feed) network. It uses Wormhole internally to distribute price data but is not a general-purpose messaging or bridging protocol a DAO would use to move treasury instructions or assets.
Added Circle's CCTP as the most directly relevant cross-chain rail for a USDC-denominated treasury, including Circle's early-2026 acquisition of Interop Labs (Axelar's IP).
Added a real, dated security incident (the May 2026 Squid/"SquidRouterModule" exploit affecting 86 Gnosis Safe wallets across Ethereum and Base, ~$3M drained) as concrete evidence for the module-risk discussion, replacing generic risk language with a sourced example.
Added 2025 bridge-hack loss data (~$2.8B, ~40% of Web3 exploit value) for risk-budget context.
Added current Wormhole network-support changes (Scroll deprecated April 2026; Moonbeam scheduled shutdown July 31, 2026) as evidence that guardian/chain coverage is not static and should be periodically re-verified before relying on any given route.
Regulatory section retained and dated: SEC/CFTC joint five-category taxonomy (March 17, 2026), GENIUS Act (signed July 2025), CLARITY Act (stalled in Senate, ~40–50% passage odds).
The five-step "Deployment Protocol" was reframed from a prescriptive, product-like sequence to an explicitly illustrative starting point, since no single vendor offers this as a packaged flow today.
All numeric/code-style diagrams in the original are treated as conceptual illustrations, not documentation of a specific shipped architecture.

This article reflects publicly available information as of July 2026. Cross-chain protocol support, security postures, and regulatory status change quickly — verify current details before making treasury decisions.