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>GET /api/v1/tokens/activity?before_seq=<seq>&limit=<count>POST /api/v1/tokens/spendApp scoping
Product purchases, spends, invoices, receipts, and spend nonces can carry app_id. Permanent-address Monero deposits credit the global account balance because the address identifies a person rather than an app. Daochi validates that an app is registered before accepting app-scoped spending or purchasing. 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 app asset permission. A supplied X-Daochi-Tx envelope is verified, but unsigned token requests remain supported while token client integration is still pending.
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.
Buy or gift with Monero
Each account receives one permanent Monero subaddress. Sending XMR to your own address buys tokens for you. Sending XMR to the address resolved from another account's alias or public ID gifts tokens to that account. Both actions use the same settlement path.
Daochi records the transfer, waits for the configured confirmation threshold and an unlocked, non-double-spent output, then converts the atomic XMR amount with integer arithmetic and issues one idempotent signed credit.
GET /api/v1/tokens/purchases/monero/addressGET /api/v1/tokens/purchases/monero/address/@aliasGET /api/v1/tokens/purchases/monero/depositsThe online node holds only a view-only merchant wallet. The mnemonic and private spend key remain offline and are never needed to allocate addresses or confirm deposits.