Live on Base, real Aave withdrawals

Set your exit. Walk away.

Exit Keepa watches your DeFi position and automatically executes the permitted exit when your condition is met.

Exit Keepa token

$KEEPA

Contract Address

0x0ac781fab70e83c8c5ce0fc60f502b0227a70d1c

1

function the executor can ever call

$0

gas cost on the exit, sponsored

222

tests passing in the current build

0

LLM calls anywhere in the decision path

Proof, not promises

A real execution you can verify

Exit Keepa has completed the full path from a Safe through the permission boundary and KeeperHub to a real Aave withdrawal on Base. Check the transaction yourself.

Tx: 0xc8a00cc28bf116acea722ab298d610bdbfc50a05b902aae5ab74d9da1849fd8b

Result: success. USDC returned to the Safe.

Verify on BaseScan →

How it works

Define the condition, authorize the exit, then let the system watch.

Choose a feature to learn about

What actually runs, in order

The autonomous lifecycle after your condition is met.

  1. Your Safe

    Holds the funds and the Aave position, start to finish. It never sends its private key anywhere.

  2. Zodiac Roles Modifier

    Pre-authorizes one narrow slice of power: withdraw(asset, amount, to) on the Aave Pool, asset locked to USDC, recipient locked to this exact Safe.

  3. KeeperHub

    The execution layer. Exit Keepa prepares and simulates the exact permitted call before the execution path proceeds.

  4. Aave v3 Pool

    Executes the withdraw. USDC lands back in the Safe that owned it the whole time.

Why the permission is narrow

The security model is part of the product, not a footnote.

Scoped, not trusted

The Safe's permission boundary restricts the executor to the permitted action. One function, one protocol contract, one recipient.

Simulate before it's real

Every autonomous exit is simulated before execution. If the simulation does not pass, the exit stops.

Deterministic, always

The policy check is plain boolean and arithmetic comparisons. No model or prompt decides whether the condition is met.

Your wallet stays yours

Exit Keepa never receives a Safe private key or seed phrase. Authorization is performed by the Safe's owners.

Receipts, not self-reports

A completed real execution is verified from the resulting chain state and receipt rather than treating a submitted transaction hash as proof.

Revocable

The permission lives on your Safe. Its owners can edit or revoke the authorization without giving Exit Keepa custody of the Safe.

KeeperHub

Exit Keepa decides when. KeeperHub handles the execution path.

Exit Keepa watches the condition, checks the policy, builds the deterministic transaction and prepares the simulation. KeeperHub is the execution layer used by the real path. The Safe remains the owner and the permission boundary stays in force.

1Trigger
2Prepare
3Simulate
4KeeperHub
5Execute
6Verify

Current execution scope

Chain

Base

Protocol

Aave v3

Action

USDC withdrawal to the Safe

The scope is intentionally narrow. It is a working execution path, not a claim of broad protocol coverage.

Try the sandbox

Click Try the demo to get a private sandbox session. It walks the autonomous lifecycle without a wallet, funds, or a real broadcast. Demo completion is explicitly separate from a real onchain execution.

Common questions

What is Exit Keepa?

A way to protect a DeFi position from a bad rate move. You set an exit condition once, and when it's crossed, a pre-approved transaction runs through your own Safe. Exit Keepa never holds your keys or your funds.

How does it actually work?

You create a strategy: the condition and the exact withdrawal it should trigger. Once it's active, Exit Keepa watches for that condition. When it's met, it prepares the transaction, simulates it, and only then can it be sent. Every step is recorded.

Why does Exit Keepa use KeeperHub?

KeeperHub is what actually calls your Safe on your behalf. It can only call one function, execTransactionWithRole, through your Roles Modifier. It has no way to call anything else, on any other contract.

What happens before an exit is sent?

Exit Keepa rebuilds the exact transaction from your saved strategy every time, runs it as a simulation, and only allows a real send once that simulation comes back clean. Nothing is ever built from data entered at the last second.

How does simulation work?

The same transaction is sent to KeeperHub in simulation mode. It's checked against the real Roles Modifier and the real Aave Pool on Base, a genuine test, not a guess, and returns either a clean result or the exact reason it would fail.

What protects my Safe?

A Zodiac Roles Modifier. By default it can do nothing. The live permission scopes the role to exactly one function, withdraw() on Aave's Pool on Base, with the asset locked to USDC and the recipient locked to this exact Safe. No other function, contract, token, or destination is reachable through it, enforced onchain by the Roles Modifier itself.

How do I set up the Zodiac Roles permission for my own Safe?

You don't have to figure this out from scratch. Register your Safe on the Dashboard, and if it doesn't have Roles enabled yet, Exit Keepa shows a step-by-step panel there and on every strategy: a link that opens the official Zodiac Roles app for your exact Safe, and a Check again button once you've granted it. Your Safe's own owners sign it there, in Safe's own app, nowhere on Exit Keepa. If you just want to see the product first, Demo mode gives you your own sandbox Safe with this already set up, so you never have to touch it to try Exit Keepa.

Does Exit Keepa control my funds?

No. Your Safe holds your funds at all times. Exit Keepa, through KeeperHub, can only trigger the one narrow action your Roles permission allows. It can't move funds outside that scope, and it never takes custody.

Can I try this without a real position?

Yes. Demo mode gives you your own private sandbox, no wallet extension required, so you can create a strategy, review the exact transaction, and simulate it with nothing at risk. It's isolated per visitor, not shared, and simulating in it is mocked rather than a real KeeperHub or onchain call - the real, verified proof is the transaction shown separately above.

What happens if an execution fails?

A failed simulation is recorded as failed, with the real reason, and it's never sent. If a real broadcast fails from a network or timeout issue rather than a clear rejection, that's recorded differently too, so an uncertain attempt is never mistaken for a success or a clean failure.

How do I know an exit actually happened?

We only store a transaction hash if it's real and well-formed, never invented. Check it yourself on BaseScan. The blockchain, not our database, is what actually proves it happened.

Set the condition. Walk away.