Trust & failure model

What is self-custodial, what is centralized, what can fail, and what users should expect when it does.

Smart-contract riskDCA Onchain is live on Base mainnet. The contracts are tested, reviewed, and audited on chain, and an end-to-end lifecycle was verified by a mainnet canary before launch, but smart-contract systems can still contain bugs and the protocol is newly launched. Size any exposure according to your own risk tolerance.

What self-custody means here

Your USDC is held in a strategy account created for you. The operator does not get a withdrawal key. The executor cannot pull arbitrary amounts, cannot withdraw to itself, cannot change who receives your buys, and cannot change your selected asset.

Self-custody does not mean nothing external matters. It means the protocol is designed so external actors have narrow powers and failures generally stop execution rather than give someone custody of your funds.

Who you trust, and for what

Actor or system	What it can do	What it cannot do	Main risk
Your wallet	Create, fund, pause, resume, withdraw, claim pending output.	Change immutable strategy settings after creation.	Wallet compromise can withdraw your strategy funds because it is the owner.
Executor	Trigger due batches through `executeBatch`.	Withdraw user funds, execute early, over-pull, change settings, lower the oracle floor.	Liveness and key management. A compromised key can waste gas or trigger due batches within contract limits, and nothing beyond that.
Owner (timelock)	Change protocol config: fees within caps, treasury, swap router, oracle, asset allowlist, approved yield implementations. Every one of these is delayed two days and publicly queued first.	Withdraw from user strategy accounts, mutate existing strategy parameters, pause, replace the executor, or act without the delay.	Admin misconfiguration can route future execution badly. You get two days of notice.
Guardian (2-of-3 Safe)	Pause and unpause instantly; replace the executor address instantly.	Change routing, fees, the oracle, or the asset list. Touch any user balance. Block withdrawals. Shorten the timelock delay.	A compromised guardian can halt execution (denial of service) or point execution at an address of its choosing, which still cannot pull more than each account's scheduled amount or redirect output away from owners.
Treasury Safe	Receives execution fees and yield fees.	Control user strategy funds.	Fee recipient compromise affects protocol revenue, not user custody.
Aave V3	Holds idle USDC when yield is enabled. Not wired in on the current deployment.	Change your strategy settings.	Aave smart-contract or market risk, affecting yield-enabled idle USDC only.
Uniswap V3	Executes swaps.	Pull funds except through the approved adapter flow.	Liquidity, price movement, and routing failures.
Price feeds	Set the independent on-chain price floor.	Execute swaps or move funds.	Stale, down, wrong, or misconfigured feeds cause reverts or a bad floor.
Automation host / RPC / Quoter	Run automation, read state, quote routes, submit transactions.	Bypass on-chain validation.	Downtime delays scheduled buys.

What can never be changed for an existing strategy

After creation, the following values are immutable in the strategy account: owner, target asset, amount per execution, frequency tier, yield enabled flag, yield adapter, batch executor address, and factory address. There is no referrer field, because no referral attribution is stored at all.

Admins can change protocol-level settings for future behavior, but they cannot rewrite an existing strategy into a different asset, a different amount, or a different owner.

What the operator can change

The owner can update capped fee parameters, the treasury address, approved yield adapter implementations, minimum amounts, the swap router, asset allowlist entries, adapter routes, and oracle configuration. The guardian can pause strategy creation or batch execution, and can replace the executor address.

These powers exist because the protocol depends on external systems whose addresses and health differ by chain: tokens, yield venues, exchanges, price feeds, and automation providers. The trade-off is explicit admin trust around configuration.

How long an admin change takes

Two days, for anything that could affect where your money goes. The swap router, the price oracle and its underlying feeds, the asset list, the fees, the treasury, and the approved yield implementations are all owned by a timelock: a change is queued publicly on chain first and cannot take effect for two days.

Two things are instant, on purpose:

Pausing. A stop button you have to wait two days to press is not a stop button.
Replacing the executor address. That key is the one most likely to leak, and swapping it cannot move anyone's funds on its own.

Neither of those can change routing or touch your balance. And you can withdraw the entire time, including while the protocol is paused.

Be clear about what the delay does and does not buy you. It does not make it impossible for a compromised admin to make a harmful change; after two days, a change can still go through. What it guarantees is notice and time to leave. That is the honest version: it turns "trust us" into "you have two days to get out."

For this to be usable you have to actually find out. Queued changes are visible on chain, and surfacing them in the app as a persistent warning, naming what is pending and when it becomes executable, is part of the production-readiness work rather than something already shipped. A public queue nobody is told about is not a real escape hatch.

One further limit worth stating: the guardian Safe also holds the timelock's proposer and executor roles, so it can queue a change and later execute it. That does not let it shorten the delay. And the deploying address holds no role at all: its privileges were revoked in the same deployment that granted the timelock ownership, and the deployment refuses to complete otherwise.

What happens if automation fails

On the current deployment there is no automation to fail: batches are triggered manually. In production, if the automation host, the configured RPC, the quoter, the executor wallet, or the scheduling configuration fails, scheduled buys can be delayed or missed.

Missed execution does not give anyone custody of funds. Your USDC remains in your strategy account or in its Aave adapter if yield is enabled. The account stays withdrawable. When automation recovers, it resumes from the current protocol schedule window; it does not automatically buy every missed historical window.

What happens if pricing protection fails safe

The protocol is designed to prefer no trade over an unsafe trade. If the executor quote fails, the script skips the batch. If the on-chain oracle is missing, stale, unsupported, or detects the Base sequencer is down or recently recovered, executeBatch reverts and no swap happens.

This protects users from a bad price, but it also means buys can be delayed during oracle or sequencer incidents.

What happens if pricing protection is misconfigured

The protocol launched only with direct USD feeds for WETH and cbBTC. If a future governed addition uses composed pricing, configuring an exchange-rate feed instead of a market <asset>/ETH feed could make the floor wrong during a depeg. That future addition must verify feed addresses through on-chain description() reads and add an off-chain divergence monitor before activation.

The contract cannot know whether a feed was chosen for the right economic reason. This is an operator trust assumption, and it is one of the reasons production oracle configuration is a distinct readiness gate rather than something the current deployment demonstrates: the current deployment uses a manual testnet oracle and prices only WETH.

What happens if Aave fails

If yield is disabled, Aave is not in your fund path. If yield is enabled, idle USDC sits in Aave through a per-account adapter. When a scheduled buy is due, the strategy tries to withdraw the exact per-execution amount from Aave. If that withdrawal fails, the account is skipped for that window without being auto-paused.

On full withdrawal, the account withdraws its full Aave position, calculates yield only if the returned amount is above tracked principal, pays the capped yield fee on that positive yield, and sends the rest to the owner.

What happens if output delivery fails

The strategy account first tries to transfer purchased tokens to the strategy owner. If the token transfer returns false or reverts, the account records the amount as pending and keeps the tokens in the strategy account. The owner can call withdrawPending(asset) later.

Recovery claims what the account actually holds, not the recorded figure. The two can differ for a token that takes a fee on transfer or adjusts balances downward, and claiming the recorded figure in that case would fail and leave the tokens stuck. The recorded number is what authorises the claim; the balance is what moves.

What happens if the protocol is paused

There are separate pauses. Pausing the factory blocks new strategy creation. Pausing the BatchExecutor blocks batch execution. Neither pause blocks user withdrawal from a strategy account.

A pause is an emergency brake for new activity, not a custody freeze.

What is not guaranteed

No guarantee that every scheduled window executes exactly on time.
No guarantee of a particular price, only minimum-output checks for each submitted batch.
No guarantee that Aave yield is positive or available.
No guarantee that external protocols such as Aave, Uniswap, the price feeds, the underlying chain, RPC providers, or the automation host remain available.
No guarantee that smart contracts are bug-free.
No guarantee that a compromised admin can never make a harmful configuration change. Such a change is delayed two days and publicly visible first, and you can withdraw throughout; that is notice and an exit window, not prevention.
No guarantee that a compromised guardian cannot halt execution. Pausing is instant by design. It cannot touch your balance and cannot block your withdrawal.