Resource · 2.3 in the design proposal

Data Account

Write append-only entries to a dedicated data chain under an ADI, and read them back — the clearest single fit for tamper-evident record-keeping in the whole proposal.

6 operations 5 MVP candidates 1 Phase 2+ (DA05)

What a Data Account is, and the guarantee it actually provides

A Data Account is a sub-account under an ADI (acc://bob.acme/data) dedicated to storing arbitrary entries. Per 004.References/AboutAccumulate.md, it inherits the same chain-of-chains model as every other Accumulate account — but the property that matters most here is that writes are append-only: there is no protocol-level "edit this entry" operation. Once DA02/DA03 writes an entry, it's on the account's own chain permanently.

That's a structurally different guarantee than "we have good database access controls" — it doesn't depend on trusting whoever holds UPDATE rights, including BizFirst's own admins. The honest tradeoff, stated plainly in the source material: it's slower, it costs credits (see Credits), and it can't be undone if you write the wrong thing. This is a tool for the subset of workflow steps where immutability is the actual point, not a wholesale replacement for the audit/history tables BizFirst already has.

Operations

Code	Operation	Maps to	Why a workflow author wants it	Priority
DA01	Create Data Account	`TxBody.CreateDataAccount()`	Set up a tamper-evident record store under an ADI (e.g. audit-trail target)	MVP
DA02	Write Data	`TxBody.WriteData()`	Write an entry to the caller's own data account — the audit-trail use case	MVP ★
DA03	Write Data To	`TxBody.WriteDataTo()`	Write an entry to a different target data account (cross-account writes)	MVP
DA04	Query Data Entry	V2 `query-data`	Read back a specific data entry, e.g. to verify a workflow's own prior write	MVP
DA05	Query Data Set (range)	V2 `query-data-set`	Bulk-read a range of entries — more of a reporting/explorer use case than a per-workflow step	Phase 2
DA06	Get Data Account Transaction History	V2 `query-tx-history` scoped to the data account's `acc://` URL	List transactions (writes) against this specific data account — explicitly requested by the owner alongside ID06/TA08 as a must-have, distinct from DA04/DA05 which read entry contents rather than write history	MVP ★

How it works — write, then verify your own write

DA02 write → DA04 read-back round trip

sequenceDiagram
  participant WF as Workflow (e.g. contract approval step)
  participant DA as DataAccountService
  participant SDK as Acme.Net.Sdk (SmartSigner)
  participant CHAIN as Data Account chain (acc://.../data)

  WF->>DA: DA02 Write Data("drafted", metadata)
  DA->>SDK: TxBody.WriteData() -> SignSubmitAndWaitAsync
  SDK->>CHAIN: append entry (immutable the moment it's written)
  CHAIN-->>SDK: confirmed within 3s, or pending
  SDK-->>DA: write result
  DA-->>WF: continue workflow

  WF->>DA: DA04 Query Data Entry (verify own prior write)
  DA->>CHAIN: query-data
  CHAIN-->>DA: entry contents, unchanged since DA02
  DA-->>WF: verified before proceeding

DA06 — reconstructing a full audit timeline

flowchart LR
  A["DA01 Create Data Account
(one per contract / case / filing)"] --> B["DA02 write: drafted"]
  B --> C["DA02 write: reviewed"]
  C --> D["DA02 write: approved"]
  D --> E["DA02 write: filed"]
  E --> F["DA06 Get Transaction History"]
  F --> G["Auditor sees the full timeline —
no possibility an intermediate step was silently edited"]

Business use case — tamper-evident compliance and approval trails

From 001.BusinessIdeas/README.md §2.1

A contract-approval workflow, a regulatory filing, or a chain-of-custody record for sensitive documents all share the same shape: a sequence of steps that must be provably unaltered after the fact. Today that's a database table with created_at/updated_at columns and an implicit trust that no one touched it out of band. Instead: DA01 creates a dedicated account per case, DA02 writes an entry at each meaningful step, DA06 pulls the full write history for an auditor, and DA04 reads back a specific entry to verify a prior write.

Called out in the source document as the single clearest fit in the whole proposal: a direct, mechanical answer to a mutable-audit-log failure mode that a normal database genuinely can't solve without external tooling (a WORM store, or a blockchain-anchoring service) — which is exactly what Accumulate already is.

Open questions affecting this resource

Open · V2 vs. V3 targeting

DA04/DA05/DA06's V2 method names (query-data, query-data-set, query-tx-history) were verified against protocol source; V3 parity was not. Applies to this resource the same way it applies to every other read-side operation in the node.