Resource · 2.6 in the design proposal

Credits

Convert ACME into the credits that pay for every write operation's transaction fee — small in operation count, but a near-universal prerequisite for everything else in this node.

3 operations 3 MVP candidates 0 Phase 2+

Why credits exist at all

Accumulate doesn't charge transaction fees directly in ACME. Every write operation costs credits, which are funded by converting ACME (see 004.References/AboutAccumulate.md §2 — a Key Page carries "a credit balance used to pay for the page's transactions"). That means every ADI creation, token send, data write, or key-page change in this node ultimately depends on the signing Key Page having a sufficient credit balance — which is why this small resource sits quietly underneath almost every other one.

Operations

Code	Operation	Maps to	Why a workflow author wants it	Priority
CR01	Add Credits	`TxBody.AddCredits()`	Converts ACME → credits, which pay for every other write operation's transaction fee — a near-universal prerequisite step	MVP ★
CR02	Query Credit Balance	V2 `query` (against a key page)	Check whether a signer has enough credits before attempting a write, to fail fast with a clear error	MVP
CR03	Query ACME/Credit Oracle Rate	`AccumulateHelper` oracle helper	Needed to calculate how much ACME to convert for a target credit amount	MVP

CR03 flagged as not independently verified

The design proposal marks CR03 MVP but with an explicit caveat: the exact underlying V2 endpoint/account URL for the oracle rate was not independently verified — confirm against SDK source before implementing. AboutAcmeNetSdk.md references AccumulateHelper's oracle/credit-math helper, but this project could not independently confirm which V2/V3 method or system account URL it queries under the hood.

How it works — the gate in front of every write

CR01/CR02/CR03 — fund, check, and calculate before writing

flowchart TD
  Q["CR03 Query ACME/Credit Oracle Rate"] --> CALC["Calculate ACME needed
for target credit amount"]
  CALC --> ADD["CR01 Add Credits
(ACME -> credits on the signing Key Page)"]
  ADD --> BAL["CR02 Query Credit Balance"]
  BAL -->|sufficient| WRITE["Any write op proceeds:
ID01/ID02, TA01-TA07, DA01-DA03,
KM01-KM07, SS03, SS04"]
  BAL -->|insufficient| FAIL["Fail fast with a clear error
instead of a failed transaction mid-batch"]

Business use case — credit management as workflow plumbing

From 001.BusinessIdeas/README.md §2.7

Not a use case anyone builds a workflow around for its own sake — but a workflow that does any of the Identity, Token Account, Data Account, or Key Management write operations eventually needs this as a supporting step, not a standalone pitch. "Credits run out mid-workflow" is a realistic operational failure mode, and CR02 is this resource's answer to catching it before a write fails partway through a batch, rather than after.

Open questions affecting this resource

Open · CR03's exact oracle endpoint

AccumulateHelper's oracle/credit-math helper is referenced in AboutAcmeNetSdk.md, but the underlying V2/V3 method or system account URL it queries has not been independently confirmed. This is the one open question that is specific to this resource rather than shared with others.