Resource · 2.2 in the design proposal

Token Account

Hold and move ACME or custom Accumulate-native tokens under an ADI — single payments, batch disbursement, balance checks, and (Phase 2) custom token issuance.

8 operations 5 MVP candidates 3 Phase 2+ (issuance: TA05–TA07)

What a Token Account is

A Token Account is a typed sub-account nested under an ADI's URL — e.g. acc://bob.acme/tokens — holding a balance of ACME or a custom token. This is a direct instance of Accumulate's account model from 004.References/AboutAccumulate.md §2: "accounts" here are purpose-specific sub-chains under an identity, not a single balance tied directly to a keypair the way an EVM chain's address works. Every send from a Token Account is a transaction that goes through the identity's Key Book authority and, per the protocol's synthetic-transaction mechanism, the receiving account's balance is credited by a protocol-generated follow-on transaction rather than updated in the same atomic step — which is why the SDK's SmartSigner polls for delivery rather than treating "submitted" as "settled."

Operations

Code	Operation	Maps to	Why a workflow author wants it	Priority
TA01	Create Token Account	`TxBody.CreateTokenAccount()`	Set up a place to hold ACME or a custom token under an ADI	MVP
TA02	Send Tokens (single recipient)	`TxBody.SendTokensSingle()`	Core payment operation — pay one counterparty	MVP ★
TA03	Send Tokens (batch)	`TxBody.SendTokens()`	Payroll-style disbursement to many recipients in one transaction	MVP
TA04	Query Token Balance	V2 `query`	Pre-transaction balance validation, portfolio/status checks	MVP ★
TA05	Create Custom Token (issuer)	`TxBody.CreateToken()`	Stand up a new token type — needed for token-issuance use cases, not everyday payments	Phase 2
TA06	Issue Tokens	`TxBody.IssueTokens()`	Mint additional supply under an existing custom token issuer	Phase 2
TA07	Burn Tokens	`TxBody.BurnTokens()`	Reduce token supply — same use-case tier as TA05/TA06	Phase 2
TA08	Get Token Account Transaction History	V2 `query-tx-history` scoped to the token account's `acc://` URL	List transactions against this specific token account — payment history, reconciliation	MVP

Every write op here waits on the 3-second confirmation policy

Per the owner's 2026-07-02 decision (design proposal §4.7), TA01–TA07 all submit through SmartSigner and wait 3 seconds after submit. If confirmed within that window, the operation returns a normal synchronous success. If not, it returns a pending/not-yet-confirmed status and the workflow follows up via QX01/QX03 or TRIG01 — see the SmartSigner page for the full mechanics of this boundary.

How it works — a single payment, submit to settlement

TA02 — Send Tokens (single recipient)

sequenceDiagram
  participant WF as Workflow
  participant TA as TokenAccountService
  participant SF as SignerFactory
  participant SDK as Acme.Net.Sdk (SmartSigner)
  participant NET as Accumulate Network

  WF->>TA: TA02 Send Tokens(recipient, amount)
  TA->>SF: resolve credentialId -> keypair
  SF->>SDK: new SmartSigner(client.V3, keypair, signerUrl)
  TA->>SDK: TxBody.SendTokensSingle(recipient, amount)
  SDK->>NET: SignSubmitAndWaitAsync(principal, body)
  NET-->>SDK: transaction accepted by sender's authority
  NET-->>NET: synthetic transaction credits recipient account
  SDK-->>TA: delivered (within 3s) or pending
  TA-->>WF: success, or pending + follow up via QX01/TRIG01

TA03 — Batch send fan-out (payroll-style disbursement)

flowchart LR
  W["Workflow: run payroll"] --> C["CR02 Query Credit Balance
fail fast if insufficient"]
  C --> B["TA03 Send Tokens (batch)"]
  B --> R1["Recipient 1
acc://vendor-a.acme/tokens"]
  B --> R2["Recipient 2
acc://vendor-b.acme/tokens"]
  B --> R3["Recipient N…"]
  B --> H["TA08 Get Token Account
Transaction History (reconciliation)"]

Business use case — programmable payments and disbursements

From 001.BusinessIdeas/README.md §2.3

Any workflow that currently ends in "...then someone manually sends a payment" is a candidate — provided the payment is denominated in ACME or an Accumulate-native token. TA01 sets up a payout account, TA02 handles one-off vendor payouts or refunds, TA03 batches payroll-style disbursement to many recipients in one transaction, TA04 checks balance before disbursing to fail fast rather than attempt an under-funded payment, and TA08 pulls history for reconciliation.

The realistic audience is narrower than the Data Account or Key Management use cases: it only matters to a workflow that already has, or wants, Accumulate-denominated asset exposure — not a general fiat-payment replacement.

Open questions affecting this resource

Open · V2 vs. V3 targeting

TA04/TA08's V2 method names were verified against protocol source; whether the node ultimately targets V2, V3, or lets the SDK's unified client decide per call is still open — confirm against docs.accumulatenetwork.io at implementation time.