Bringing Accumulate into BizFirst’s workflow engine
BizFirst’s workflow platform runs on a plugin model — a self-contained, reusable
ExecutionNode a workflow author drags onto a canvas: send an email, query a
database, wait for approval, call an API. This project builds the node(s) that let a BizFirst
workflow talk to Accumulate
— an identity-based blockchain protocol — by wrapping
Acme.Net.Sdk, the community-maintained C# SDK for it.
Not “blockchain” as a checkbox — three specific properties
For most BizFirst workflows, a database row and a normal API call are the right tool, and
nothing here argues otherwise. Accumulate earns a node because of three concrete protocol
properties, not because blockchain is fashionable — see
001.BusinessIdeas/README.md for the full argument, including where this
explicitly is not a fit.
Tamper-evident record-keeping
A Data Account is append-only — there is no UPDATE statement. For the subset
of workflow steps where “could someone edit this after the fact” is a real
business risk (compliance trails, chain-of-custody), that's a structurally different
guarantee than good access controls. It's slower and costs credits, and it isn't a
wholesale replacement for BizFirst's existing audit tables.
Non-repudiable multi-party authority
BizFirst's ApprovalNode already models “2 of 3 must approve.” A Key
Page's m-of-n threshold makes that approval cryptographically provable — each
signature is an artifact, not a database row asserting a user was logged in. Stronger when
a decision might need defending to a regulator, auditor, or counterparty.
Native value transfer
Token Account operations move ACME or an Accumulate-native asset directly. This isn't a claim that blockchain payments beat ACH/wire/card rails — it's relevant specifically to workflows that already hold or need to move an Accumulate-denominated asset.
Where the ExecutionNode sits
A 3-project SRP split (Domain / Services / Executor), mirroring the pattern already used by
BizFirst's Ethereum ExecutionNode. The signing key is never stored raw in node settings — it's
resolved at execution time via ICredentialResolver, the mandatory Credential
Pattern used across every BizFirst ExecutionNode.
flowchart TB A["Workflow Author
drags a node onto the canvas"] --> B["AccumulateNodeExecutor
(routing, credential resolution)"] B --> C["ICredentialResolver
credentialId to keypair"] B --> D["Resource Service
Identity / TokenAccount / DataAccount / KeyManagement / SmartSigner / Credits / QueryExplorer"] C --> E["SignerFactory
builds a SmartSigner"] D --> E E --> F["Acme.Net.Sdk
TxBody + SmartSigner.SignSubmitAndWaitAsync"] F --> G["Accumulate Network
BVN validates, DN anchors"] G -. "synthetic transactions settle cross-ADI effects" .-> F
9 resources, 46 operations — sourced from the design proposal
Each card below is one dedicated page covering that resource's protocol concepts, its full
operation table (code, SDK mapping, priority), at least one Mermaid diagram of its mechanics,
open questions that specifically affect it, and a business use-case callout where one exists.
Every operation code traces back to
002.Requirements/00_NodeDesignProposal.md — nothing on this site is invented.
acc:// identity every other resource nests under.ITriggerNodeExecutor) — start a workflow when a new transaction lands on a watched account.Some design decisions cut across multiple resources rather than living inside one operation table. Signing Pathways is the first one: how a write operation actually gets signed — auto-sign, HIL approval with a vault-or-agent credential, or HIL approval where the approver's reply already carries its own signature (which flows straight into SS05 on the SmartSigner page). Find it in the sidebar under "Design Notes."
Where to start, in order
No prior blockchain experience required. Anyone comfortable with C#/.NET who's curious about Accumulate's identity-based architecture — or who just wants to help build something real for the BizFirst community — can jump in.
004.References/AboutAccumulate.md — identities (ADIs) instead of address-as-identity, the acc:// URL/account model, Key Books & Key Pages, synthetic transactions. Start here even if you've used other chains before.004.References/AboutAcmeNetSdk.md — Acme.Net.Sdk's namespaces, the TxBody builder surface, the SmartSigner signing model, and a working quick-start example.002.Requirements/00_NodeDesignProposal.md — the resource/operation breakdown this entire site is built from, plus the decision log and open questions. A living document — check its status header.
This project started from a real update: community developer
jason_gregoire
maintains Acme.Net.Sdk
— the C# SDK unifying Accumulate's V2 and V3 APIs with Ed25519 signing, transaction builders,
and identity-hierarchy tooling. Thank you, Jason, for building and maintaining it — this
project wouldn't exist without it.
| Folder | Purpose |
|---|---|
| 001.BusinessIdeas/ | Why this matters, use cases, motivation — the "why" layer |
| 002.Requirements/ | Node design proposals — resources, operations, architecture (draft, evolving) |
| 003.ApiSpec/ | The detailed, finalized API specification — reserved for the project owner to write once the design in 002.Requirements/ is settled |
| 004.References/ | Background reading on Accumulate the protocol and Acme.Net.Sdk the library |