# Undertow bounded execution — mainnet pilot reference Status: factory and production service deployed — restricted mainnet pilot — no independent audit Date: 2026-11-05 Network: Robinhood Chain mainnet, chain ID 4663, gas ETH UTOW has no required payment, staking or governance role ## Product boundary Current production supports encrypted plans and wallet-signed USDG to WETH batches Two 1 USDG automatic batches executed in plan contract 0x53668515FB0ab9c2Bb4E446817dd4c840784E489 The second broadcast required operator assistance during the pilot Automatic execution starts only after explicit plan funding and encrypted handoff It does not turn the current token allowance into automatic trading authority ## Architecture decision Use an immutable factory and one non-upgradeable vault per plan Each vault holds only that plan's deposited USDG budget and records its own progress No pooled customer accounting, proxy upgrades, arbitrary call or delegatecall The owner's wallet remains the sole withdrawal recipient and the sole WETH recipient A designated executor pays gas and submits constrained executeBatch calls The owner may replace or remove that executor at any time The operator has no owner override and no withdrawal capability V1 charges no protocol fee and pays no executor reimbursement from customer funds The dedicated production executor uses its ETH fee reserve — low reserves or fee limits can delay execution Funding flow: approve exact USDG budget to the factory, then createAndFund Expect two owner transactions when allowance is absent Do not promise one signature or assume USDG supports ERC-2612 The factory transfers exactly the approved budget into the newly created vault Check the vault balance delta equals the requested budget or revert creation The factory keeps no customer balance and grants no ongoing operator allowance ## Production addresses and route USDG: 0x5fc5360d0400a0fd4f2af552add042d716f1d168 WETH: 0x0bd7d308f8e1639fab988df18a8011f41eacad73 Existing application router: 0xcaf681a66d020601342297493863e78c959e5cb2 Factory: 0x288e7edDa1A610E9F08fD227608f88D950aC8deb Executor: 0xCa627340f34E230553db9b508B5353ea71b07b1A The execution path checks chain identity, configured router, pool pair and token configuration before preparing a batch Each vault uses the fixed configured router and token addresses Construct exactInputSingle calldata internally rather than accepting arbitrary executor calldata The implemented router call uses the deployed RH exactInputSingle parameter shape Only direct USDG to WETH pools and explicitly configured fee tiers are allowed No arbitrary recipient, intermediate token, bridging or external fee recipient ## Immutable plan configuration owner, planId, chainId, inputToken, outputToken, router, factory budget, maximumBatchAmount, batchCount, minimumInterval, globalExpiry scheduleRoot committing all private batch instructions Executor address is owner-replaceable but cannot change plan constraints Store remainingBudget, totalSpent, totalReceived, nextBatch, lastExecutedAt and control state Use integer base units — USDG has 6 decimals and WETH has 18 decimals V1 supports at most 120 sequential batches Changing budgets, price floors or the schedule means cancelling and creating a new plan No in-place budget expansion or silently expanded allowance ## Private schedule commitment Each Merkle leaf commits chainId, owner, planId, index, amountIn, minimumOut, notBefore, notAfter and a random 32-byte salt Use typed abi encoding and double-hashed leaves with a standard reviewed Merkle proof library The factory binds a unique owner-scoped planId to one vault and prevents reuse The chain sees the root and global caps at creation, then each executed leaf and proof Salts prevent cheap guessing of short schedules from a root Before funding, the client validates every leaf, contiguous indices, the sum of all input amounts == budget and all time bounds against global caps The root cannot prove that the full schedule is usable on its own — the owner review must show the complete committed schedule The full future schedule stays encrypted in the user's vault The executor necessarily learns the schedule needed to execute it V1 uses an explicitly consented encrypted handoff to a dedicated executor service This is privacy from the public chain before execution, not privacy from the chosen executor User recovery keys remain client-side and are never handed to the executor Use a separate encrypted runner payload containing only this plan's execution leaves and proofs No claim of anonymous trading, hidden funding, hidden counterparties or hidden past fills ## Onchain execution rules executeBatch(leaf, proof) is callable only by the current executor or owner Require Active, nextBatch < batchCount, correct chain and vault binding, valid proof and index == nextBatch Require amountIn > 0 and amountIn <= maximumBatchAmount and remainingBudget Require minimumOut > 0 and notBefore <= block.timestamp <= notAfter <= globalExpiry For all batches after the first require block.timestamp >= lastExecutedAt + minimumInterval A delayed batch cannot cause a burst of catch-up executions The owner commits any acceptable leaf expiry window before funding The executor may choose an allowed fee tier but may not reduce the leaf minimumOut Use checks-effects-interactions with a standard nonReentrant guard Update spent budget and next index atomically with the swap — every failure reverts both Approve only this batch amount to the fixed router and clear the allowance after success Check actual USDG balance decrease equals amountIn and actual WETH increase meets minimumOut Have the router send WETH to the vault, measure its increase, then transfer exactly that increase to owner in the same transaction A failed output transfer reverts the entire batch Record actual input, output and batch index in BatchExecuted Do not count donations to the vault as deposited budget or executed output ## Price protection decision V1 enforces an owner-committed absolute minimum WETH output for each batch This is an explicit price floor, not a guarantee of a fixed percentage slippage against the current market A quote submitted by the same executor cannot independently prove current fair market price The runner must obtain fresh quotes and simulate execution before sending, but the contract trusts only owner-committed bounds The runner must skip execution when quotes cannot meet the floor A malicious or compromised executor may still deliver only the allowed floor, so users must see that limit clearly before funding MEV and adverse selection remain possible within the owner's bounds A dynamic market-relative slippage mode is deferred Enable it only after an independent RH price source is selected and reviewed for liquidity, observation history, manipulation cost, staleness, decimals and chain outage behavior No Chainlink feed or TWAP availability is assumed by this document If that validation fails, keep the absolute-floor mode or leave automation disabled ## Pause, cancel and exit Active -> Paused -> Active is owner-controlled Active or Paused -> Cancelled is permanent All batches executed -> Completed is derived from nextBatch == batchCount Expired plans cannot execute cancelAndWithdraw atomically cancels and returns remaining USDG to the owner Owner withdrawal while active must first make the plan cancelled in the same transaction A paused plan can resume only if its budget and time constraints still hold Withdrawals remain available during pause and after expiry without operator approval No administrator emergency switch can lock withdrawals Once a batch is included before the cancellation, it cannot be undone by a later cancellation The transaction order on the canonical chain determines which action takes effect Unexpected token donations can be recovered only by the owner without touching other users' vaults ## Runner and reorganization behavior Persist jobs by chainId + vault + batch index, not by wall-clock timer alone Before submitting, read onchain nextBatch, control state, balance, time bounds and exact simulation Use one pending transaction per executor account and reconcile nonce before retry Multiple runners cannot execute the same index twice — the contract is the authority A successful included receipt may unlock the next due batch without waiting for finality Track transaction block hash and log identity separately from finality After restart or reorg, read canonical vault state and rebuild progress from logs Never infer success from a submitted hash or a timed-out HTTP request An expired or failed attempt consumes executor gas but no successful plan budget Do not automatically retry indefinitely — bound retry count, backoff, gas budget and leaf expiry If the executor is unavailable, the owner can execute a valid batch or cancel and withdraw No contract depends on the website, Supabase or the runner to authorize owner withdrawal ## Implemented contract interfaces Factory: createAndFund(planId, config, executor) — scheduleRoot is part of config Vault: executeBatch(leaf, proof, feeTier), pause(), resume(), setExecutor(address), cancelAndWithdraw(), recoverUnexpectedToken(token) Views: config(), nextBatch(), remainingBudget(), totalSpent(), totalReceived(), totalWithdrawn(), status(), executableAt() Events: PlanCreated, PlanFunded, BatchExecuted, PlanPaused, PlanResumed, ExecutorChanged, PlanCancelled, FundsWithdrawn No delegated wallet-wide signing key or unlimited token pull from the user wallet V1 uses ordinary owner transactions rather than signed meta-transactions EIP-712 and ERC-1271 support can be added only as a separately specified and tested later feature ## Current service and release scope Vercel invokes the executor every minute Supabase persists encrypted handoffs, execution attempts, receipts and fenced concurrency locks The browser can close after funding and accepted handoff Wallet-level recovery exposes owner controls without unlocking the private vault Notifications link each funded plan to its fund records and chain receipts Contract, execution and recovery checks are recorded with the release evidence A funded mainnet plan executed both batches — the second broadcast needed operator assistance A separate funded run completed pause, resume and cancellation with a 2 USDG refund These pilot receipts are not an independent security audit or evidence of uninterrupted reliability Access remains restricted to eligible pilot wallets ## Work still outstanding Independent security audit Broader pilot readiness and operational reliability A separately reviewed price source before dynamic market-relative protection See the website documentation for current receipt links and disclosure boundaries