ANA.FI
/
AUDITABILITY & COMPLIANCE

Verifiable Execution.

The engine keeps your policy private while verifying that it runs as expected. We use modern state-of-the-art cryptography to guarantee liveness, execution correctness, and institutional-grade predictability.
HEARTBEAT
signed on-chain
CHAIN
every block, in order
ENGINE FRONTIER
← PROCESSED
PENDING →
PROCESSED
HEARTBEAT BLOCK
HEARTBEAT
Signed on-chain, recording the block it processed to.
THE BUILD
Verifiable by anyone, without seeing your rules.
ON ANOMALY
Predictable fallbacks, reverts, no freeze.
YOUR RULES
Sealed throughout.
01
NON-OMISSION

A missed payment has nowhere to hide.

Privacy and accountability usually trade against each other. Here they don't — the rule stays sealed inside the enclave, while the record of the engine running it lands in the open.
ANAFI ATTESTED ENCRYPTED ENGINE — EVERY TICK, EVERY SEALED RULE
{engine correctly processed every transaction in block M .. N}
N-5
N-4
N-3
N-2
N+1
N
N+1
the queue, in order
{non-omission proof}
READS EVERY PIECE OF DATA
The engine continuously processes every tick of on-chain or other types of data, matching the conditions of a committed rule to the actual state.
LANDS ON-CHAIN
A signed heartbeat records the block it processed to. Anyone can check it, and check the engine's build, without asking us.
02
SAFETY LOOP

A rule that would drain you never gets signed.

Anafi sanity-checks your private rules: every new rule is run against the ones you already hold.
If rule A pays rule B and rule B refills rule A, that is a loop — money going in circles while fees quietly eat the balance. The engine flags these and tells you why, in plain language.
YOU
a new rule
ANAFI ENGINE · SEALED RULES
RULE A
RULE B
RULE C
RULE D
pays
loop trigger
LOOP DETECTED — NOT SEALED
THE ENGINE DECIDES
SEALS IT
the rule lands on-chain
REFUSES IT
THIS RULE
nothing is signed · warning back to you
03
DEFINED SEMANTICS

Late data, missing blocks, colliding rules.

A payment engine lives in a world of gaps, stale prices and rules that all want to fire on the same tick. None of it is left to chance — time, faults and concurrency each have semantics written down, so the same inputs always resolve the same way.
chain
clock
prices
budgets
outbox
event
gap · 5 min
revocation
settled
optimistic
settled
frontier
+1.2%
+0.4%
−0.7%
+2.1%
13:00
13:01
budget cap
fire A
refused
fire C
retry B
TIME
A rule is evaluated against the tick it was due on. The engine records how far it has certainly processed, so nothing is decided past the frontier.
FAULTS
A gap in the chain means refuse, not guess. Prices that went stale during the gap are not used, and the deferred rule is retried once the stream returns.
CONCURRENCY
One budget cap across every rule that wants to fire. At the cap the next rule is refused outright rather than partially paid.
04
PRE-FLIGHT CHECKS

Three checks before you sign.

A rule you cannot revoke fast enough is a rule you should never have signed. Everything that can be caught before the signature is caught before the signature.
RULE
SIGNED
WARNING — BACK TO THE USER
ENGINE WARNING SYSTEM · PRIVATE
STATIC CHECKS
STATEFUL PREDICTIONS
PLAIN LANGUAGE FORMATTER
STATIC CHECKS
Types, caps and allowlists. Dates that don't exist in every month. Anything malformed is caught before you sign.
STATEFUL PREDICTIONS
A dry run over the last 90 days. A conflict check against your other rules. A flag on any recipient you've never paid.
PLAIN LANGUAGE FORMATTER
The result is explained back to you in a sentence you can read. The explanation never makes the decision.
05
FAQ

What can be checked, and by whom.

Can't find what you're looking for?
Ask the team directly.
Talk to us
How do I check the engine is running the code you claim?
The engine runs in an Intel TDX enclave (a TEE), and we publish its attestation on chain, so anyone can verify the claim. The attestation binds the engine keys to an exact, reproducible image, and our verifier checks it with only an RPC node.
What is a signed heartbeat, and how does it prove nothing was skipped?
Every 30 minutes, the engine signs a heartbeat with its TEE key: "I folded this chain up to block N at time T." The attested code folds every block in order, so a valid heartbeat shows that the engine was live and folded every block up to N.
Can a scheduled payment be missed or executed twice?
Each payment has a unique on-chain nonce, so the contract rejects a second execution, even after a retry, a restart, or a reorg. If the engine is down at a scheduled time, it catches up and fires each missed payment once, late.
How does Anafi prevent payment loops between rules?
When you upload rules, the engine runs a sanity check inside the TEE and returns encrypted warnings that only you can read.
What happens when two rules want the same budget at the same time?
The upload sanity check warns when 2 rules spend a fixed amount of the same token.
If the automation is submitted nevertheless, the later payment reverts if the wallet cannot pay both.
What happens if the chain or a price feed has a gap?
Anafi's engine has a formal model of what happens when delays occur, and we design our system to handle concurrency corner cases such as delays or missed messages or intermittent failures with grace, providing robustness and liveness;
The engine never skips a block when the chain or the RPC fails.
What checks run before I sign a rule?
The app checks your inputs, then the engine then checks the rule inside the TEE: syntax, types, allowlists, and swap routes. The engine approves the exact rule hash, your browser checks that approval, and then you sign 1 transaction that records only the hash on chain.
Is Anafi regulated, and who handles KYC?
Anafi is non-custodial: your funds stay in a Safe that you own, and you can revoke the engine at any time. Our servers cannot read your rules, and timed or event-based transfers, swaps, and DCA need no KYC. Off-ramp comes through licensed partners, and their KYC applies; Anafi itself holds no financial licence.
GET STARTED

Go and read
the heartbeat.