Tokens
Signed receipts for app purchases and spends.
Daochi can issue configured asset receipts after verifying a payment provider or admin credit. The ledger is append-only, account-scoped, app-tagged, and readable as either account-wide or app-filtered history.
Ledger model
Every token event records issuer, asset, account, optional app_id, event type, amount delta, ledger sequence, previous hash, event hash, signature, source type, and source reference. Clients verify the Ed25519 issuer key and accept only the issuer and asset IDs they trust.
Purchases credit the account ledger. Spends debit the account ledger and require an app ID plus an idempotency key, so repeating a spend request returns the existing receipt instead of double-charging the account.
GET /api/v1/tokens/issuerGET /api/v1/tokens/productsGET /api/v1/tokens/balance?app_id=<optional>GET /api/v1/tokens/ledger?since=<seq>&app_id=<optional>POST /api/v1/tokens/spendApp scoping
Token purchases, spends, invoices, receipts, and spend nonces carry app_id. Daochi validates that the app is registered before accepting a spend or purchase flow. Account-wide balance and ledger reads remain the default. Passing app_id returns only token events for that app.
Signed app manifests can define token policies for spend and purchase. Once policies exist for an app, token actions need the matching policy and, after any declared legacy grace deadline, a valid X-Daochi-Tx envelope signed by both the account key and an active app key.
Token ledger and payment intent rows are financial audit records. App-filtered balances are audit views over those rows, not separate allocation pools. Explicit account-to-app allocation events are still needed before per-app token distribution is complete.