Technical Design Proposal

Robot Money needs two core protocol flows — agent-to-agent capital delegation and token-holder governance — and each has 2–3 viable technical approaches with sharply different tradeoff profiles. For delegation, an ERC-4626 vault is the simplest MVP path, but combining it with Safe + Zodiac Roles gives institutional-grade security. For governance, a Curve-style gauge-weight voting system adapted for allocation is the strongest fit, though Snapshot's off-chain weighted voting offers a faster-to-ship fallback. The critical security insight across both flows: vote-escrow locking solves the largest class of governance attacks (flash loans, token borrowing), while allowlisted contract interactions are the single most important guardrail for delegated agent capital.

FLOW 1: Agent delegation — three technical approaches

The core design problem is granting the RM Agent authority to trade and allocate USDC within three buckets (stables yield, agent-token trading, revenue liquid tokens) while ensuring Agent A can always withdraw. Every approach below preserves Agent A's withdrawal rights through different mechanisms.

Approach A: Pure ERC-4626 vault with role-restricted manager (recommended MVP)

How it works. Agent A calls deposit(usdcAmount, agentAAddress) on an ERC-4626 vault contract on Base, receiving proportional share tokens. The vault's internal logic grants the RM Agent an ALLOCATOR_ROLE (via OpenZeppelin AccessControl) that can call custom functions like allocateToStrategy(address strategy, uint256 amount) — but cannot call withdraw() or redeem(). Share tokens are the depositor's cryptographic proof of claim. The exchange rate totalAssets() / totalSupply() determines redemption value, rising as strategies generate yield.

Custody guarantee. Agent A holds ERC-20 share tokens in their own wallet. Withdrawal is permissionless — calling redeem(shares, receiver, owner) burns shares and returns proportional USDC. The vault manager never touches share tokens and is code-restricted from self-withdrawals. Strategy addresses are whitelisted at the contract level, so the RM Agent can only deploy capital to pre-approved Aave/Compound/Morpho pools and approved DEX routers.

Key implementation details:

• OpenZeppelin's ERC4626.sol provides the base. Custom onlyRole(ALLOCATOR_ROLE) modifier on strategy functions restricts the RM Agent. Override _withdraw to enforce receiver == owner (prevents manager from redirecting withdrawals).
• Protect against the ERC-4626 inflation attack (where an attacker donates assets to an empty vault to steal subsequent deposits) using OpenZeppelin v4.9+ virtual shares/assets offset or by making an initial "dead shares" deposit at deployment.
• For the three-bucket model, track internal accounting per bucket: bucketA_deployed, bucketB_deployed, bucketC_deployed. The totalAssets() override sums all bucket balances plus idle USDC.
• Implement a 2% annual management fee by minting fee shares to the protocol treasury at each checkpoint (harvest), and a 0.25% exit fee deducted in the _withdraw override.

Tradeoffs. Simplest to build and audit (medium complexity). Battle-tested standard with extensive tooling. However, the RM Agent's allocation authority is embedded in the vault contract itself — changing permissions requires a contract upgrade or redeployment. The RM Agent's EOA key is still a single point of failure for allocation decisions, though it cannot steal funds.

Base-readiness. Fully ready. Sub-cent gas costs make frequent deposits/withdrawals and strategy rotations economically viable.

Approach B: Safe multisig + Zodiac Roles Modifier (recommended for security-critical deployment)

How it works. A Gnosis Safe on Base holds the vault's deployed capital. The Safe owners (could be a multisig of protocol governance participants or Agent A directly) retain full custody. The Zodiac Roles Modifier module — already deployed on Base — grants the RM Agent a scoped role with granular, function-level permissions.

Permission scoping is extremely expressive. The Roles Modifier supports: target contract whitelisting (only Aave Pool, Uniswap Router, Compound cUSDC), function selector restrictions (allow supply() but block transfer()), parameter conditions (EqualToAvatar ensures recipient parameters always point back to the Safe, not the agent's own address), and rate-limited allowances (e.g., maximum $50K reallocation per 24-hour period, enforced on-chain). This means the RM Agent can execute DeFi strategies but physically cannot transfer funds to any address except the Safe itself.

Real-world validation. karpatkey manages $150M+ for ENS DAO, GnosisDAO, and Balancer through this exact pattern — non-custodial treasury management where a delegated operator trades within strict permission boundaries. Gnosis Pay (Visa-powered cards) routes every transaction through Roles for settlement whitelisting and daily transfer limits.

Implementation details:

• Deploy Safe via Safe SDK on Base. Enable Zodiac Roles module. Define permission tree using zodiac-roles-sdk (TypeScript), specifying allowed targets, functions, parameter conditions, and rate limits.
• The RM Agent's address is assigned a role. When the agent calls execTransactionWithRole(), the Roles Modifier verifies the call against the permission tree before forwarding to the target contract.
• Safe owners can revoke the role at any time, add new constraints, or execute transactions directly via M-of-N signature.

Tradeoffs. Strongest custody guarantees of any approach — the agent literally cannot exceed its permissions. Medium-high complexity: requires deploying Safe + enabling module + defining permission trees programmatically. Permission tree design requires careful thought (overly permissive = risk; overly restrictive = agent can't operate). More moving parts than a pure ERC-4626 vault.

Recommended architecture: combine A and B. Use the ERC-4626 vault (Approach A) as the depositor-facing interface. The vault's strategy allocation sends capital to a Safe (Approach B) where the RM Agent operates within Zodiac Roles permissions. This gives depositors standardized share-based withdrawal rights AND gives the RM Agent's capital movements institutional-grade constraints.

Approach C: Enzyme Finance Onyx vault on Base (highest feature completeness)

How it works. Enzyme Finance (8+ years in production, formerly Melon Protocol) provides a vault-as-a-service where a Delegated Trader role gets trading authority while depositors retain share-based withdrawal rights — mapping almost exactly to Robot Money's requirements. Enzyme's Onyx SDK explicitly supports Base (Chain ID 8453).

The permission model is purpose-built for delegated asset management. The Vault Owner sets policies: Allowed Adapters (restricts which DeFi protocols the trader can use), Allowed External Positions, Asset Disallowed Lists, Slippage Stop-Loss (cumulative slippage tolerance preventing fund misappropriation), and share transfer restrictions. The Delegated Trader address — which can be a bot or AI agent — executes trades within these constraints. Depositors buy shares (ERC-20 tokens) and can redeem at any time for their proportional NAV.

Additional features relevant to Robot Money: continuous on-chain NAV calculation, automated fee computation (management and performance fees), and a Fee Splitter contract for multi-party distribution (e.g., 70% to vault owner, 30% to delegated manager). Enzyme has won Hedgeweek's "Blockchain Technology of the Year" 2025 and has been audited by both ChainSecurity and OpenZeppelin.

Tradeoffs. Highest feature completeness — everything Robot Money needs is already built. Medium complexity to integrate via Onyx SDK (~50 lines for vault deployment). However, introduces a dependency on Enzyme's contract infrastructure and upgrade path. MLN token fees apply at the protocol level. Enzyme's adapter set may not cover every DeFi protocol Robot Money wants to interact with on Base (would need to verify Aave/Compound/Morpho adapter availability on Base specifically). Less customizable than building from scratch.

FLOW 2: $RM token holder governance — three technical approaches

The governance flow has two distinct phases: (1) token-gated proposal submission where agents must hold $RM to nominate their token for the allocation shortlist, and (2) weekly allocation voting where broader $RM holders set weights across shortlisted tokens. Each approach below handles both phases differently.

Approach A: Curve-style gauge controller adapted for allocation (recommended)

How it works. This is the most battle-tested model for exactly Robot Money's use case — periodic voting that directly controls allocation weights. Deploy a custom GaugeController-inspired contract on Base where each "gauge" represents a token on the allocation shortlist. $RM holders lock tokens for veRM (vote-escrowed RM) with linear decay over 1–52 weeks. veRM holders call vote_for_gauge_weights(token_address, weight_bps) to allocate their voting power (0–10,000 basis points) across shortlisted tokens.

Weekly epoch mechanics. New weight votes take effect every Thursday at 00:00 UTC (following the Curve/Balancer convention). A 10-day per-gauge cooldown prevents rapid vote-flipping between epochs. The vault reads finalized gauge weights at epoch start and rebalances accordingly via Chainlink Automation on Base (~$0.50–5 per weekly execution, negligible cost).

Token-gated proposal submission. To add a new token to the gauge list, an agent must hold ≥ X veRM (suggested 0.5–1% of circulating supply) and call proposeGauge(tokenAddress). This mirrors Governor Bravo's proposalThreshold mechanic. The proposal enters a 3-day voting period where veRM holders approve/reject inclusion. Once approved, the token becomes a permanent gauge eligible for allocation votes (removable only by governance).

The bribe market flywheel. This approach naturally enables the "agents buy $RM to lobby" mechanic. Agents wanting vault allocation to their token can either: (a) accumulate veRM themselves and vote, or (b) bribe existing veRM holders through platforms like Hidden Hand or a native incentive marketplace. During peak Curve Wars, protocols spent eight-figure sums per week on bribes, with $1 in bribes yielding $1.50+ in emissions value. For Robot Money, this creates a self-sustaining flywheel: agents pay for allocation → $RM holders earn yield → demand for $RM increases.

Security properties. Vote-escrow locking is the single strongest defense against flash loan governance attacks — locked tokens cannot be flash-borrowed. The Beanstalk hack ($182M, April 2022) was possible precisely because governance tokens were not locked and voting + execution occurred in the same transaction. veRM with minimum 1-week lock eliminates this entire attack class. The 10-day cooldown per gauge prevents rapid vote manipulation between epochs.

Implementation complexity: medium-high. Requires porting Curve's GaugeController from Vyper to Solidity and adapting it to control treasury allocation weights instead of emissions. The VotingEscrow contract is well-documented open source. Weekly epoch + Chainlink Automation execution is straightforward.

Approach B: Snapshot weighted voting with on-chain relay (fastest to ship)

How it works. Use Snapshot's off-chain governance with weighted voting — a built-in voting type where voters distribute their voting power as percentages across multiple choices. This maps directly to "allocate X% to Token A, Y% to Token B, Z% to Token C." Voting is gasless (signed messages stored on IPFS), with power determined by $RM balance at a snapshot block.

Proposal creation uses Snapshot's validation strategies: configure the Robot Money space to require minimum $RM holdings (e.g., 50M tokens = 0.05% of supply) to create proposals. Proposers submit their token for shortlist inclusion. Broader $RM holders vote using weighted voting to set allocation percentages.

The execution gap. Snapshot votes are off-chain — results must be bridged on-chain to trigger vault rebalancing. Three options: (1) a trusted multisig reads Snapshot results and submits an on-chain transaction (simplest, least trustless), (2) an optimistic oracle (UMA-style) posts results on-chain with a challenge window, or (3) Snapshot X with Zodiac Safe module execution (most trustless, but currently Starknet-native — reading Base balances requires custom storage proofs not yet available).

Additional voting types available. Beyond weighted voting, Snapshot natively supports ranked-choice (IRV), quadratic voting, and approval voting — all configurable per proposal. This gives Robot Money maximum flexibility to experiment with voting mechanisms without contract changes.

Tradeoffs. Fastest to ship (low complexity). Gasless voting maximizes participation. Battle-tested with 9,645+ spaces and 500K+ monthly users. However, the off-chain-to-on-chain execution bridge introduces trust assumptions. The multisig relay is a centralization point. Flash loan resistance depends on snapshot block selection (taken at proposal creation, before voting starts — generally safe, but not as robust as ve-locking).

Approach C: Custom OZ Governor + Agora voting module on Base (fully on-chain)

How it works. Deploy a custom OpenZeppelin Governor contract on Base with a purpose-built counting module that supports multi-option weighted voting (replacing the default For/Against/Abstain). Use Agora as the governance frontend — Agora powers Optimism governance and has strong Superchain/Base alignment, offering custom voting modules via proposeWithModule.

On-chain voting on Base costs ~$0.01–0.05 per vote, making weekly cycles economically viable. A 3-day voting period + 1-day timelock = 4-day cycle fits weekly cadence. The Governor's proposalThreshold enforces minimum $RM holdings for proposal creation (standard functionality, configurable in constructor).

Custom AllocationVotingModule. The core engineering challenge is building a Solidity counting module that accepts weighted votes across N options and computes final allocation percentages. Each vote encodes (tokenAddress[], weightBps[]) where weights sum to 10,000. The module aggregates votes weighted by $RM balance, computes final percentages, and the timelock executor calls vault.rebalance(weights).

Execution layer. After the voting period ends and the proposal succeeds (meets quorum + allocation logic), it's queued in a TimelockController. After the timelock delay, anyone can call execute(), which triggers the vault's rebalance() function with the voted weights. Alternatively, Chainlink Automation monitors the timelock and auto-executes when the delay expires.

Tradeoffs. Fully on-chain and trustless — no off-chain relay needed. Direct execution path from vote to vault rebalance. Medium-high complexity: requires building a custom counting module (no existing implementation for multi-option weighted allocation exists in OZ Governor). Agora provides UI but custom allocation voting would need custom frontend work. Every vote costs gas (though minimal on Base).

Recommended MVP architecture

For a shippable MVP, the lowest-complexity path that maintains security is:

Delegation stack: ERC-4626 vault (Approach A) accepting USDC deposits on Base, with the RM Agent operating via a Coinbase Agentic Wallet constrained by either Zodiac Roles (Approach B, if managing significant capital) or simple contract-level RBAC (if speed-to-ship is paramount). Nevermined handles agent-to-agent payment settlement. Enzyme (Approach C) is the upgrade path when the protocol scales beyond MVP.

Governance stack: Start with Snapshot weighted voting (Approach B for governance) with a trusted multisig relay for on-chain execution. This ships fastest and lets you iterate on voting mechanics without contract redeployments. Migrate to the Curve-style gauge controller (Approach A for governance) with veRM locking once TVL justifies the engineering investment — this is the target architecture for security and incentive alignment.

Execution: Chainlink Automation on Base for weekly vote-to-rebalance triggers. ~$0.50–5 per weekly execution.

Timeline estimate: The Snapshot + ERC-4626 + RBAC path could ship in 4–6 weeks with a small team. The full gauge controller + Safe/Roles + Chainlink Automation architecture is an 8–12 week build requiring audit.

The most critical architectural decision is whether to adopt ve-tokenomics (locking $RM for veRM). This single choice determines flash loan resistance, incentive alignment, bribe market dynamics, and long-term protocol defensibility. The Curve/Balancer model has proven this works at scale — Convex accumulated over 50% of circulating CRV specifically because gauge weight control is valuable. For Robot Money, where agents are economically motivated to influence allocation, ve-locking creates the strongest possible alignment between governance participation and long-term protocol health.