Crypto neobanks are gaining traction precisely because users prioritise UX. But users also need automation. In the US, 25% of the bills are paid automatically [1], with 67% household bills automatic in Australia [2], and direct debit accounting for about 70% of all recurrent payments in EU [3] and UK [4].
Part of Web2 neobanks' popularity can be attributed to seamless automation: scheduled payments, round-ups, salary splitting, auto-investing. Web3 automation, by contrast, is non-existent or terribly complex. To compete with web2 neobanks, web3 and stablecoin-oriented neobanks and wallets must be equally intuitive and UX-friendly.
Trust and delegation. How do you delegate execution without losing non-custodiality? You can write a smart contract script, but how can you be sure it's secure and does not give more rights than you expect? Simple delegation protocols exist across ecosystems, but they typically define only on-chain rules, and rather loosely so — "only swap these tokens", "do not withdraw funds", or "only rebalance between these wallets". No product solves automation well today — they either defer to a third-party watchtower, propose complicated intent optimisation auctions, or push the responsibility entirely onto the user. For a neobank or wallet, building their own automation layer is costly and introduces an extra layer of security risks and compliance headaches.
Simplicity. Most average consumers gravitate towards simpler, convenient, understandable products first [5]. This stands in stark contrast with complicated DeFi yield vaults with unclear regulatory implications, or AI-optimised on-chain hedge funds, that web3 commonly suggests to retail customers. Features such as simple auto transactions, direct debits, stablecoin rebalancing, all non-custodial, and owned by the end user — are largely overlooked in web3. Stablecoins and RWAs, growing in popularity and adoption faster than ever, could become "normal" instruments for average neobank users, and represent known, and already well-understood assets. However, we believe that this transition is likely to be stymied without a simple, user-focused approach to financial management.
Privacy. Privacy is a huge bottleneck for wider blockchain adoption. Aside from being one of the biggest trends of 2025/2026, privacy is fundamental — web3 currently lacks the luxury of confidentiality that users of tradfi neobanks take for granted.
Anafi aims to address all three by providing simple, secure, and private automation infrastructure.
Anafi is a privacy-preserving decentralized automation engine. The core technical proposition of Anafi is the infrastructure layer for neobanks, wallets, and RWA providers, built to ship automated, private, non-custodial financial automation to their end users, fast.
Our core features:
We believe the solution we provide lives best in the B2B2C model — Anafi integrates with neobanks and wallets as backend infrastructure, while end users interact through partner apps with a Monzo/Revolut-style simple interface. Low barriers to entry, globally accessible.
We first present the complete vision of Anafi, with an MVP scope defined right after.
Confidential execution substrate — a privacy-preserving runtime that holds user strategies and signing keys. Triggers, balances, and policy state are hidden from third parties.
Automation & triggers — the MPC collectively evaluates when an action should fire.
Execution — two paths:
Settlement, account model, on-off ramp integration:
DSL & programmability:
Basic multi-account pseudonymity:
Provable liveness (research direction) — the maximalist version of the privacy story: not just hiding execution, but cryptographically proving that every trigger that should have fired did fire. Realised through "private supervisor" oracles — TEE/MPC quorums that ingest the public world, evaluate opaque trigger sets, and emit slashable attestations when an operator misses a trigger.
For our Q2 2026 MVP, we have to prioritise the most important features first:
See "deferred features" below for what we do not include at the start.
For B2B2C, partners (neobanks, wallets) need to integrate Anafi easily.
MVP deliverables internal-facing:
MVP deliverables for partners (external-facing):
Target: Late Q2 2026 (MVP launch)
Phase breakdown:
MVP requires basic money movement. Key integrations to consider:
Explicitly out of scope for MVP, but on the roadmap:
balance(TOKEN), last.X, running_total), composite triggers (any_of / all_of), pipelined and atomic action composition, named budget pools and rolling-window capsrandomized_delay.)uses:-style imports for third-party triggers and actions, with content-hashed pinning, sandboxing, and tiered trust (verified / audit-stamped / community)The primary function of Anafi's DSL is to capture the automation/delegation strategy, concisely expressing in a human-readable way: (1) triggers, (2) actions, (3) red line checks and restrictions.
Example DSL declarations that we support:
randomized_delay wrappers — cron and event triggers fire at a uniform-random offset in a user-chosen window.agent_envelope: token allowlist, recipient allowlist, per-tx max, balance floor — all enforced statelessly at redemption.We use YAML with custom expressions as the canonical surface — round-trippable to a visual builder, lintable, and familiar to anyone who has authored a GitHub Actions workflow. Structurally, the DSL borrows from GitHub Actions (trigger-then-actions decomposition, uses:-style plugin model for community modules) and Nix (typed module system, content-hashed dependency graph — the on-chain commitment plays the role of flake.lock). YAML is the human-facing surface; the on-chain commitment is over the typed, resolved AST.
Example specification — illustrating triggers (incoming_tx, cron, cron_schedule, price_changed, randomized_delay privacy wrapper), actions (send_one, send, exchange, lock, notify), value expressions (percentages, FX-style of conversion, named constants and address book), and an agent_envelope for autonomous-agent spending:
# ── Variables, constants, address book ───────────────
# Plain string aliases, typed constants, and named-address
# entries — referenced symbolically by the rules below.
variables:
cold_wallet: "0xColdWallet0000000000000000000000000000001"
employer: "0xEmployerAddr00000000000000000000000000001"
constants:
dca_amount: "100 USDC"
address_book:
landlord: { addr: "0xLandlord0000000000000000000000000000001", label: "Landlord" }
rules:
# ── Rule 1: Monthly rent ─────────────────────────────
# 1st of every month at 09:00 — fixed EUR amount paid
# in USDC via on-the-fly FX conversion (`of`).
monthly_rent:
trigger:
type: cron_schedule
day_of_month: 1
time_of_day: "09:00"
actions:
- type: send_one
to: "$book.landlord"
value: "1200 EUR of USDC"
# ── Rule 2: Salary auto-split ────────────────────────
# When a paycheck (1000–10000 EUR) arrives from the
# employer: 50% cold storage, 30% brokerage, 10% into
# ETH, 10% locked until next salary day.
salary_split:
trigger:
type: incoming_tx
from: "$employer"
value: "1000..10000 EUR"
sender_type: "employer"
actions:
- type: send
recipients:
- { to: "$cold_wallet", value: "trigger.value * 50%" }
- { to: "0xBrokerage000000000000000000000000000001", value: "trigger.value * 30%" }
- type: exchange
in: "trigger.value * 10%"
out: ETH
- type: lock
value: "trigger.value * 10%"
unlock_trigger:
type: cron_schedule # unlocks at next 1st-of-month
day_of_month: 1 # (at-most-once when used as unlock)
time_of_day: "09:00"
# ── Rule 3: Daily DCA with privacy delay ─────────────
# `randomized_delay` wraps any non-wrapper trigger and
# adds a uniform-random delay — here 5min–1h after the
# daily cron — so block-explorer observers can't infer
# the schedule from regular block timing.
dca_eth_private:
trigger:
type: randomized_delay
inner:
type: cron
interval_seconds: 86400
delay_min_sec: 300
delay_max_sec: 3600
actions:
- type: exchange
in: "$dca_amount"
out: ETH
# ── Rule 4: ETH price alert (edge-triggered) ─────────
# Fires once per directional crossing, not on every
# sample above threshold.
eth_high_alert:
trigger:
type: price_changed
symbol: ETH
condition: above
threshold_usd: 5000
edge_only: true
actions:
- type: notify
channel: push
message: "ETH crossed $5000 — review portfolio"
# ── Agent envelope (use case B) ──────────────────────
# Hand a session key to an AI research agent so it can
# pay for API calls and RPC services autonomously,
# within a privacy-preserving balance envelope.
# Stateless caps: USDC balance must stay above 500 after
# every spend; no single tx may exceed 50 USDC.
agent_envelope:
to: "0xResearchAgentKey00000000000000000000000001"
token_allowlist: [USDC]
recipient_allowlist:
- "0xOpenAIPaymaster0000000000000000000000000001"
- "0xRPCProvider000000000000000000000000000001"
balance_floor: "500 USDC"
per_tx_max: "50 USDC"
expiry: "2026-12-31T00:00:00Z"
# ── Global constraints ───────────────────────────────
global:
token_allowlist: [USDC, USDT, EUR, EURC, ETH]Operator precedence in value expressions: of is the lowest-precedence operator — trigger.value * 50% of EUR parses as (trigger.value * 50%) of EUR. The conversion always happens last. The canonical pretty-printer wraps non-atomic LHS of of in parens for unambiguous reading.
DSL SDK toolset features the following checkers (with examples):
Consistency checker — validates internal correctness before deployment. Basic type-checking and language-level checks.
| Check | Status | Message |
|---|---|---|
| Undefined reference | ❌ | Error: variable $hot_wallet used in rule sweep_to_cold but not declared in variables / constants / address_book |
| Address format | ❌ | Error: 0x123 is not a valid 20-byte hex address |
| Token allowlist violation | ❌ | Error: rule dca_eth exchanges into SOL, not in global.token_allowlist |
| Dimensional mismatch | ❌ | Error: cannot add USDT + ETH in swap_leg.value — bridge with of first |
Chained of conversions | ⚠️ | Warning: 30 USDT of ETH of EURC — double conversion loses precision |
Volatile source in of | ⚠️ | Warning: 1000 ETH of USDT — ETH price could spike between evaluation and settlement |
Tight randomized_delay window | ⚠️ | Warning: delay window 30s — privacy benefit is marginal |
| Cross-rule resource conflict | ⚠️ | Warning: rule dca_eth and sweep_to_cold may race on USDT balance |
| Agent envelope without expiry | ⚠️ | Warning: agent_envelope has no expiry — long-lived envelopes are an audit risk |
Compiler — transforms DSL into target execution environments. Here presented as a set of CLI commands, but available as an SDK/through an API. Targets:
Sanity checker — static analysis for financial risk and operational clarity.
$ anafi analyze rules.yaml --monthly-summary
Projected monthly outflows:
dca_eth: ~400 USD (4x weekly)
salary_split: ~4500 USD (90% of expected salary)
rent_payment: 1200 USD (fixed)
─────────────────────────────
Total: ~6100 USD/monthRule 'sweep_to_cold' moves 90% of large incoming txs
=> consider if 0xEmployer changes payment schedule
Rule 'momentum_dca' uses external RSI oracle
=> verify oracle feed reliability
No global spend cap defined
=> consider adding monthly_max_outflow constraintConflict: 'rebalance_bands' (targets 60/40 ETH/USDC) may
counteract 'dca_eth' (increases ETH allocation monthly)
Suggestion: Add exclusion window or unify allocation targetsanafi simulate rules.yaml --scenario salary_received.jsonScenario: User wants to automatically (1) send 500 USDC to a friend and (2) buy 200 USDC worth of ETH whenever they receive their monthly salary.
Setup phase:
incoming_tx from 0xEmployer, value 2000..10000 USDCsend_one 500 USDC to 0xFriendexchange — 200 USDC for ETHPUT /v1/profile), and commits it in the user's account under "delegated to my_strategy" section.Execution phase (monthly, when salary arrives):
GET /v1/executionsFor partner integration we provide two toolsets: a REST API (with optional SDK) and an embeddable UI widget.
REST + OpenAPI spec. All requests are signed by user's wallet (e.g. Phantom signMessage), with partner identification via API keys.
Core endpoints:
GET /v1/profile # current delegation rules
PUT /v1/profile # update delegation rules
POST /v1/profile/pause # pause all or specific rules
POST /v1/profile/emergency-stop # kill switch — halt everything
GET /v1/executions # execution history (for reporting/accounting)
GET /v1/executions/:id # single execution details
GET /v1/notifications # failed payments, alerts, etc.Example: update a rule
curl -X PUT https://api.anafi.io/v1/profile \
-H "Authorization: Bearer <signed-message>" \
-H "X-Partner-ID: partner-wallet-app" \
-d '{"rules": {"dca_eth": {"trigger": "weekly", "amount": "150 USD"}}}'Privacy note: all queries are constructed client-side (Fireblocks/TEE style) — the network never sees plaintext delegation rules.
We envision the main integration path to be through partner's own frontend plus our SDK, but we provide wireframes and the widget as a day 1 drop-in solution if necessary. Implemented as iframe/webview or React component — easily integratable, customizable styling, works out of the box.
Main tabs:
Supported features:
Optional — partners can replace with native UI or use as fallback. UX inspiration: Monzo/Revolut, yield.xyz, DCABot, Glider.