Non-Custodial Design

How Ava is structured so your funds never leave your wallet — and what the safety boundary actually is.

Non-Custodial Design#

Safety first. You're in complete control. Always.

The three pillars:

  • Transparency — every action is visible. You see each step in the chat, and every on-chain action is verifiable on a block explorer. Nothing happens silently.
  • Security — non-custodial by design. Funds never leave your wallet. You hold your keys. The Guardian acts only within on-chain spend caps you set — limits it cannot exceed.
  • Control — you're always in charge. You approve every action before it runs. Adjust the caps, pause the Guardian, or revoke its permission entirely — anytime, on-chain.

The rest of this page is the detail behind those three sentences.

Where your funds actually are#

In your wallet. Not on Ava's servers, not in an "Ava balance" you topped up, not in a multi-sig vault we control. The accounts that hold your funds are accounts you control. There is no Ava database row that says "user X has Y USDC."

What Ava is — concretely#

Ava is two things:

  1. A language interface in Telegram that helps you understand and decide.
  2. A bounded permission on your smart wallet (or a permission attached to your EOA via a controller) that lets Ava initiate specific kinds of on-chain transactions within specific caps you set.

The permission is the entire trust boundary. It's on-chain, it's verifiable, and it's revocable.

The shape of the permission#

When you authorize Ava for, say, a Liquidation Guard on Aave, you sign one transaction that creates a permission with:

  • Authorized actor: the Guardian operator (a specific address).
  • Authorized contracts: the Aave Pool contract (and a small set of helpers).
  • Authorized actions: supply() / repay() for this position.
  • Spend caps: e.g. at most 500 USDC, at most 0.2 WETH from this wallet, refilled monthly.
  • Lifetime: until you revoke. No silent expiry, no silent renewal.

The on-chain policy enforces every line above. Ava cannot exceed the cap. Ava cannot call a contract that isn't on the allowlist. Ava cannot drain you, even if Ava were fully compromised — because the chain itself refuses.

What Ava can and cannot do#

Ava can…Ava cannot…
Read public on-chain data about your walletRead your seed phrase or private key (it doesn't have them)
Read your portfolio via data providers (e.g. Zerion)Move funds to addresses outside your authorized scope
Propose a concrete action and simulate itExecute an action without your tap-confirm
Execute a confirmed action inside your spend capsExceed the caps — the on-chain policy enforces this
Watch and alert 24/7Trade speculatively, time the market, or use leverage on your behalf
Revoke its own permission if you ask it toStop you from revoking it directly on-chain

The "trust nothing, verify everything" path#

Every action Ava takes lands on-chain. You can verify each one:

  1. Ask Ava for the transaction hash, or open the wallet's recent activity.
  2. Inspect the transaction on a block explorer (Etherscan, Basescan).
  3. Check from (your smart wallet), to (the authorized contract — e.g. Aave Pool), and the amounts.

If a transaction ever lands that you didn't expect, revoke first, ask later: revoking is one transaction and immediately stops any future action.

What if Ava is wrong?#

Ava can be wrong — bad recommendation, bad timing, missed risk. The non-custodial design means "wrong" is bounded:

  • Wrong recommendation → you decline. No funds move.
  • Wrong simulation → on-chain guards (slippage, allowlist, caps) catch it. Funds stay safe.
  • Bad luck (oracle anomaly, market gap, congestion) → at worst Ava spends inside the cap on a poor outcome. There's no path where Ava can hurt you beyond the cap.

That's the whole point of the design: bound the worst case explicitly, on-chain, so you can sleep.