Anafi: Technical Product Vision

  1. Motivation — why automation matters for crypto
  2. What is Anafi — product overview and core features
  3. Technical Vision — architecture and security model
  4. MVP Scope — what is included in the first version
  5. Delegation is Code: DSL Design — rule language and tooling
  6. Example Workflow — salary auto-split end to end
  7. Integration API/UI — REST API and embeddable widget

Motivation

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.

What is Anafi?

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:

  1. Automated execution
    • Automate transfers: direct debits, auto rebalancing, auto payments (bills/salaries), split expenses, salary management.
    • Simplify savings and investment: auto-investment (e.g. monthly DCA/TWAP), weighted/proportionate allocation, sector-based allocation, and rebalancing rules.
  2. Trusted: Secure and private non-custodial delegation
    • User's automation expressed in clear, safety-checked DSL, executed by Anafi servers
    • Non-custodial, directly settled: users are in control and own their funds.
    • Decentralized and secured by cryptographic assumptions and economic incentives.
    • Privacy: ZK proofs of execution correctness—users verify delegation rules are followed. Enabled by ZK/TEE advances; fully delegated to chain.
  3. Clear UX
    • Designed for clarity while enabling extensive, partner-customizable programmability.
    • Anafi provides SDK and API, along with UI widget and wireframe references making integration easy and fast.
    • With Anafi, users understand what is going on with their finances.
  4. Stablecoin and RWA focused
    • RWAs, stablecoins, and basic crypto tokens as primary investment resources (not complex DeFi yield schemes)
    • Integration with RWA providers and stablecoin issuers
  5. Report generation & auditability
    • Compliance-friendly audit trails and financial reporting.

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.

Technical Vision

We first present the complete vision of Anafi, with an MVP scope defined right after.

  1. MPC network — a small set of nodes (Chainlink/Renegade/Fireblocks/Phala style) that hold user strategies and contract fragments in a secret-shared / TEE-encoded manner.

    • Privacy is achieved by MPC or TEE directly.
    • The security of our protocol is derived from the (1) TEE guarantees, (2) BFT / MPC honest majority, (3) economic assumptions and fraud proofs — parties in our MPC can be liable in non-participation if the transaction was supposed to be triggered.
    • Decentralization is achieved by allowing participants to join some sub-sections of the MPC.

  2. Automation & triggers — the MPC collectively evaluates when an action should fire.

    • Uses timelock crypto (simplest case: external time oracle) + secret sharing of dates + secure comparison.
    • For this we include oracle integration — external data (prices, time) flows into the network and can be referenced by triggers. We are actively considering using Symbiotic-style AVS for oracle data in the future.

  3. Execution — two paths:

    • Threshold signing (MPC+TEE): nodes jointly create and sign a transaction Fireblocks-style, then broadcast it. Can be signature-on-TEE-execution, or "provable MPC" without TEEs.
    • Collaborative zkSNARK (Renegade-style): parties generate a proof together. Especially useful for private/shielded transactions (e.g. confidential coins/RWAs).
    • Either way, the transaction hits the chain and settles.
    • Bonus pseudonymity by randomized triggers: triggers/execution can be slightly delayed for privacy — e.g. "evaluate condition X; schedule action within random interval in the next hour/day".

  4. Settlement, account model, on-off ramp integration:

    • We aim to make our account model as lightweight as possible — delegation is a "small extra" on top of a "normal looking account". No complex big smart contracts with opaque ownership.
    • For delegation we need something like AA (Account Abstraction) with delegated ownership (AA / PDA) to verify MPC threshold sigs or SNARKs as proof of ownership, and an on-chain DSL interpreter.
    • With Anafi, settlement is direct: users own their funds normally, not just shares in some auto-managed vault.
      • Funds settlement itself is just a regular transaction that our backend creates in a secure and delegated way. Everything that the user delegates looks like a normal transaction.
    • We are compatible with common automated on/off-ramp designs: where payment is necessary to be made to a one-time address for e.g. off-ramp.
    • Future support of privacy-preserving tokens is possible. We can support accounts within a confidential pool (Aleo/Secret Network/Elusiv/Light protocol style). Railgun/0xbow target stronger anonymity than our compliance model requires, but remain potential future integrations.

  5. DSL & programmability:

    • We design a DSL expressing "how to automate/delegate" (see paragraph below).
    • It's a simple declarative language with three parts: (1) triggers (time/oracle conditions), (2) actions (interact with accounts/token contracts), (3) restrictions/optimisation (max fee, exchange choice, slippage, allowed tokens — CoW/intent protocol style).
    • The "actions" part is interpreted on-chain (1inch swapVM style).
    • All three components compile to MPC-friendly bytecode for node execution.
    • For future SNARK provability: we also compile triggers/restrictions into circuit language — proving actions fired at correct conditions and the action plan satisfies user constraints.

  6. Basic multi-account pseudonymity:

    • For MVP, we support "pseudonymity" rather than full privacy: users can create and automatically manage many single-use accounts (AA+paymaster style), the link between which is known only to the user and Anafi.
    • Accounts are treated as UTXO-like containers — new accounts created for incoming funds, any account can be used for outgoing. Hierarchical derivation presents them as "one account" to the user.
    • Anafi stores account to user mappings and can disclose to compliance partners (RWA providers, on/off-ramp) on request. Optionally, users can post encrypted user IDs with ZKP to enable partner-side linking without on-chain visibility.
    • This is not "fully private" (correlation attacks possible), but also orthogonal to our main privacy approach, regulation-compliant, and sufficient for MVP. Full MPC/ZK privacy is post-MVP.

MVP Scope

For our Q2 2026 MVP, we have to prioritise the most important features first:

  1. Core backend: TEE + a single server + on-chain rails. Fireblocks/turnkey-style without MPC. Our own oracle data. Basic pseudonymity via multi-account storage can be supported as described above.
  2. DSL: simple automation, transfers, purchasing tokens, price and time triggers.
  3. Settlement: public transactions, settlement with some public contract rails + TEE receipt publishing.

See "deferred features" below for what we do not include at the start.

MVP Deliverables

For B2B2C, partners (neobanks, wallets) need to integrate Anafi easily.

MVP deliverables internal-facing:

  1. TEE execution service — enclave that stores strategies, evaluates triggers, signs transactions
  2. Chain indexer / listener — monitors on-chain events for trigger conditions (incoming txs, price changes)
  3. DSL compiler & validator — parses YAML specs, runs consistency checks, compiles to TEE format
  4. On-chain contracts — user account contracts (AA/PDA), delegation verification, DSL interpreter
  5. Backend API server — REST endpoints for partner integration, execution logging, notifications

MVP deliverables for partners (external-facing):

  1. REST API — strategy CRUD, execution history, notifications (spec in doc below)
  2. SDK — TypeScript/JS wrapper, possibly Rust for Solana
  3. Wireframes + optional UI widget — while we focus on the SDK approach, we provide wireframes and iframe/webview or React component for day-1 integration and testing.
  4. Documentation — integration guide, DSL reference, example flows

MVP Timeline & Phasing

Target: Late Q2 2026 (MVP launch)

Phase breakdown:

  1. Foundation — DSL spec, TEE infrastructure setup, basic contract architecture. UI / widget started from first weeks in parallel.
  2. Core Execution — DSL interpreter (on-chain or TEE-based), trigger detection, transaction building
  3. Integration — Partner SDK/API, widget development, on/off-ramp integration
  4. Testing & Hardening — Security review, testnet deployment, partner pilot

On/Off-Ramp & External Integrations

MVP requires basic money movement. Key integrations to consider:

  1. On/off-ramp provider — enable users to fund accounts, withdraw to bank.
    • We provide our own integration with an on/off-ramp provider, e.g. Bridge (Stripe), Transak, MoonPay.
    • At the same time, we are aiming to integrate partner-specific on/off-ramp provider where necessary.
    • Integration should be uncomplicated, as Anafi's delegated actions are regular transactions, so the naive integration workflow will be quite similar to ours.
  2. DEX/swap routing — for token purchases within strategies
    • Options: Jupiter, 1inch/0x.
  3. Time and price oracles (post MVP) — for time and price-triggered strategies (DCA, rebalancing)
    • Options: in-house at the start for MVP, but could consider e.g. Pyth or Chainlink.

Deferred Features (Post-MVP Roadmap)

Explicitly out of scope for MVP, but on the roadmap:

  1. Decentralization — MPC network with partner access, multiple TEE nodes, slashing/fraud proofs
  2. Full privacy — ZK-proven execution correctness, confidential stablecoins integration, TEE receipt verification
  3. Advanced DSL — portfolio rebalancing, weighted allocation, fee optimization/control, complex conditionals
  4. External oracles — Pyth/Chainlink integration, randomized triggers for privacy, DSL-to-MPC compilation
  5. Multi-chain — cross-chain automation, bridge integration
  6. Advanced compliance tooling — full audit trail generation, tax reporting
  7. Visual strategy builder — drag-and-drop UI for non-technical users

Delegation is Code: DSL Design

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:

  1. Basic transfers:
    • Schedule payment from A to B on time T (daily/monthly, starting date/end date)
    • If received transaction 1-3 of the month with the sum [A,B] OR from one of these addresses - send these three transactions.
    • "Split expense" with another user (similar to Monzo's bill splitting).
    • If received a transaction above 10k$, move 90% to cold storage
    • If detecting an outgoing transaction with "TAG", send an outgoing transaction with 0.5% of the cost to person Y (e.g. this can be used to implement joint expenses).
  2. Auto investment, or recurrent asset buying:
    • TWAP/DCA = "buy 1000$ of this asset monthly/weekly"
    • Value Averaging (VA) = "target 1000$ monthly portfolio growth"
    • Momentum-based DCA = "adjust purchase amount based on trend indicators"
    • Rebalancing bands: set portfolio allocation, e.g. 40/60
    • RSI-weighted DCA (relative strength index).
  3. Price and fee control:
    • 1% commission on purchases maximum (for ALL txs)
    • Do not exceed 30th percentile weekly gas price (for DCA)
  4. Notifications:
    • Notify if ethereum price above Y
    • Notify if "all crypto" / "all stablecoins" > 60% (e.g. wants to keep certain proportion of funds)
    • Notify if portfolio grows/shrinks >10% within a day.

For MVP we use YAML with custom expressions — GitHub Actions style. Easy to implement, parsers available in both TypeScript and Rust. In the future we may consider alternatives: KDL for stricter/more predictable syntax, or OPA Rego if we need better expressivity (conditionals, iterations, predicate checking).

Example specification — salary auto-split combined with a weekly DCA rule and a small-deposit sweep:

# ── Variables ────────────────────────────────────────────
# Reusable aliases — referenced by rules below.
variables:
  cold_wallet: "0xColdWallet999"
  employer:    "0xEmployerAddr"

rules:
  # ── Rule 1: Salary split ──────────────────────────────
  # When a paycheck (1 000–10 000 EUR) arrives from the employer,
  # distribute it: 50% to cold storage, 10% into ETH, 20% locked.
  salary_split:
    trigger:
      type: incoming_tx
      from: "0xEmployerAddr"         # filter by sender
      value: "1000..10000 EUR"       # bounded range, inclusive
      sender_type: "employer"        # informational tag
    actions:
      - type: send
        to: "0xColdWallet999"
        value: "trigger.value * 0.5"       # 50% to cold storage
      - type: buy
        value: "trigger.value * 0.1 of ETH"  # 10% into ETH
      - type: lock
        value: "trigger.value * 0.2"       # 20% locked away
        label: "emergency fund"
        unlock: "2026-01-01"               # earliest unlock date

  # ── Rule 2: Weekly DCA ────────────────────────────────
  # Buy 50 USDT worth of ETH every day (86 400s).
  dca_eth:
    trigger:
      type: cron
      interval_seconds: 86400        # once per day
    actions:
      - type: buy
        value: "50 USDT of ETH"      # spend 50 USDT to buy ETH

  # ── Rule 3: Small-deposit sweep ───────────────────────
  # Any incoming EUR transfer ≤ 500 gets locked automatically.
  sweep_small:
    trigger:
      type: incoming_tx
      value: "..500 EUR"             # open lower bound (≤ 500)
    actions:
      - type: lock
        value: "trigger.value"       # lock the full amount
        label: "micro-savings"

DSL SDK toolset features the following checkers (with examples):

  1. Consistency checker — validates internal correctness before deployment. Basic type-checking and language-level checks.

    CheckStatusMessage
    Undefined variable detection❌Error: variable $hot_wallet used in rule sweep_to_cold but not defined in variables block
    Address format validation❌Error: address 0x123 in whitelist_addresses is not a valid 42-character hex address
    Circular dependency detection❌Error: rules rebalance_eth and rebalance_usdc may trigger each other in a loop
    Amount sanity⚠️Warning: rule salary_split actions sum to 95% of trigger.value — remaining 5% unallocated
    Token consistency❌Error: rule dca_eth buys SOL but SOL not in global_constraints.tokens whitelist
    Constraint conflicts❌Error: rule quick_buy has max_gas_percentile: 5 but trigger is time-sensitive — may never execute

  2. Compiler — transforms DSL into target execution environments. Here presented as a set of CLI commands, but available as an SDK/through an API. Targets:

    • On-chain execution: generates calldata / instruction set for on-chain interpretation (1inch swapVM-style)
    • MPC bytecode output: for threshold-signed execution.
    • TEE enclave format: for Fireblocks/Turnkey-style single-server implementation, and for MPC+TEE in the future.
    • ZK circuit (future): for proving execution correctness.

  3. Sanity checker — static analysis for financial risk and operational clarity.

    • Monthly outflow projection: 
      $ 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/month
    • High-risk rule flagging: 
      Rule '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 constraint
    • Competing strategy detection: 
      Conflict: 'rebalance_bands' (targets 60/40 ETH/USDC) may
    counteract 'dca_eth' (increases ETH allocation monthly)
Suggestion: Add exclusion window or unify allocation targets
    • Execution simulation — dry-run with mock events or historical data to evaluate strategy performance: 
      anafi simulate rules.yaml --scenario salary_received.json

Example Workflow: Salary Auto-Split

Scenario: 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:

  1. User connects to the partner app
  2. User creates a delegation rule via UI builder (DSL snippet):
    • Trigger: incoming_tx from 0xEmployer, value 2000..10000 USDC
    • Action 1: send 500 USDC to 0xFriend
    • Action 2: buy 200 USDC of ETH
  3. User signs the delegation config with their wallet (proves ownership)
  4. Partner app submits encrypted config to Anafi API (PUT /v1/profile), and commits it in the user's account under "delegated to my_strategy" section.
  5. Anafi TEE stores the strategy (secret-shared with user for recovery)

Execution phase (monthly, when salary arrives):

  1. Salary tx lands on-chain: 0xEmployer → User, 5000 USDC
  2. Anafi backend detects incoming tx matching trigger conditions
  3. Anafi backend evaluates constraints inside MPC/TEE (gas price acceptable? slippage within bounds?)
  4. Anafi backend constructs two transactions:
    • Tx A: User → 0xFriend, 500 USDC
    • Tx B: User → DEX, swap 200 USDC for ETH
  5. Anafi backend signs transactions using delegated authority (AA session key / PDA)
  6. Transactions broadcast to chain and settle
    • The on-chain script checks that the actions are according to the DSL strategy snippet committed before.
    • 0xFriend contract might be an off-ramp service that auto-detects any incoming transactions and initiates a bank transfer according to the tx metadata.
  7. Anafi logs execution, user can query via GET /v1/executions
  8. (Optional) User receives notification: "Salary split complete: 500 USDC sent, 0.08 ETH purchased"
Setup
User
1
Partner App
2
Anafi API
3
Anafi Backend
1. Connect wallet, create rule, sign
2. PUT /v1/profile (encrypted config)
3. Store strategy (secret-shared)
Execution (monthly)
Employer
5000 USDC
salary tx
1
Chain
Contains trigger and
action txs
2
Anafi Backend
  • Detect trigger
  • Check constraints
  • Build transactions
  • Sign (AA/PDA)
3
Result
✓ Tx A: User → 0xFriend/off-ramp — 500 USDC settled
✓ Tx B: User → DEX — 200 USDC → ETH settled

Integration: API and UI Module

For partner integration we provide two toolsets: a REST API (with optional SDK) and an embeddable UI widget.

API

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.

Embedded UI Widget / Webview

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:

  1. Payments — schedule one-time or recurring payments, payroll (batch recipients)
  2. Invest — auto-invest (DCA/TWAP/VA), rebalancing rules
  3. Activity — scheduled items list, execution history, cancel/edit actions

Supported features:

  • Schedule a payment — one-time future transfer (e.g., pay invoice on March 1st)
  • Recurring payments — fixed amount on schedule ($500 rent monthly)
  • DCA / Auto-invest — recurring buys ($100 → SOL weekly)
  • Rebalance rules — trigger swaps when allocation drifts (keep 60/40 SOL/USDC)
  • Sweep rules — auto-transfer when balance exceeds threshold (>$10k → cold wallet)
  • Payroll — batch recurring payments to multiple addresses

Optional — partners can replace with native UI or use as fallback. UX inspiration: Monzo/Revolut, yield.xyz, DCABot, Glider.