Wallets & earnings

Every account has a platform ANM balance backed by an append-only double-entry ledger. Callers spend from it; developers earn into it — in the same atomic settlement, at the moment of execution.

Funding a balance

  • Deposit ANM from your wallet to your account's deposit address (Developer Center → wallet). Deposits are credited after on-chain finality verification — the platform balance is backed 1:1 by verified deposits.
  • Promotional credits (e.g. the Founding Developer grant) are drawn down before your real balance. Credits fund executions but are not withdrawable, and credit-funded revenue still pays the developer in full — the platform absorbs the difference.

Per-execution settlement

one execution, one transaction
caller balance ──(price)──┬── platform fee (feeBps)  ─→ treasury
                          └── developer share        ─→ your balance   (same transaction)
                              (+ provider share when a fleet provider ran it)
  • Exactly once: settlement claims the execution row conditionally inside the same transaction that posts the ledger entries — a retry or two racing workers cannot double-charge.
  • All or nothing: the debit, the credits, the fee and the execution's financial fields commit together, and the entries for one execution always sum to zero.
  • Exact sum: price == platformFee + developer + provider is asserted before the transaction may commit — a pricing bug fails the execution instead of minting ANM.
  • Affordability, not escrow: before running, the platform checks balance + credits − in-flight reservations against the worst-case estimate, and refuses with 402 insufficient_funds rather than letting a run it cannot settle start.

Your earnings

The developer share lands as a SALE_CREDIT ledger posting — immediately spendable on your own usage, app purchases or animica.wallet.pay flows, and withdrawable through the marketplace payout flow.

earnings API
GET /api/cloud/v1/me/earnings?days=30
{
  "paidNanm": "…",        // settled and already spendable (SALE_CREDIT ledger postings)
  "pendingNanm": "…",     // admitted but not yet settled (quoted reservations, not income)
  "byFunction": [ { "functionId": "…", "developerNanm": "…", "executions": … } ],
  "byDay":      [ { "day": "2026-08-01", "developerNanm": "…" } ]
}

Receipts

Every execution produces a receipt with the full customer-side money breakdown:

the receipt (real values from a live example run)
// returned by the authenticated invoke API; header equivalents on the public endpoint
"receipt": {
  "requestId": "rq_…", "executionId": "…", "function": "examples/anm-toolkit",
  "version": 1, "status": "succeeded", "asset": "ANM",
  "grossNanm": "5255894", "platformFeeNanm": "1051178",
  "developerNanm": "4204716", "providerNanm": "0", "creditNanm": "0",
  "feeBps": 2000,
  "usage": { "durationMs": 1053, "cpuMs": 1053, "memoryMbMs": "134784",
             "aiTokensIn": 0, "aiTokensOut": 0 },
  "freeTier": false, "ledgerRef": "…"
}

The same numbers persist on the execution row and in your /api/cloud/v1/functions/{id}/executions history. Internal platform cost accounting (COGS, margins) is deliberately never exposed.

Integrity guarantees behind all of this: every account's cached balance must equal the sum of its ledger entries; a nightly reconciliation job re-verifies that invariant, the per-execution exact-sum invariant and the zero-sum-per-ref invariant, and raises a finance alert on any disagreement — it never "fixes" records silently.