Owns
- transaction lifecycle and persistent state
- submission, retries and replacement
- nonce coordination per signing address
- confirmation tracking to a required depth
- idempotency of every mutating call
Transaction Engine
Blockchain transaction processing for tokenization products
Production systems need durable, asynchronous orchestration around authorization, signing, submission, confirmation and reconciliation — not ad hoc HTTP calls to an RPC.
Custody providers and blockchain infrastructure services can handle parts of execution. Tokenistry provides the application-specific orchestration around them — the business operation, durable queue, signing workflow, submission, confirmation, idempotency, retries, failure handling, and transaction/domain state your product must own.
Tokenistry does not rebuild RPC endpoints or custody. The value is reliable orchestration and state around those providers so regulated tokenization operations remain durable and recoverable.
From business operation to confirmation
transaction.path
Business Op
Authorize
Queue
Sign
Submit
Confirm
Reconcile
What it carries
- business operation lifecycle
- durable / async processing
- queues
- signing workflow
- submission & confirmation
- retries & idempotency
- failure handling
- gas / nonce where relevant
- replacement handling
- transaction / domain state
- reconciliation
- operational visibility
Custody and chain infrastructure services remain the execution substrate. Tokenistry owns the application-specific orchestration around them.
FAQ
Why not just call the RPC from the application?
Synchronous fire-and-forget paths lose retries, idempotency, confirmation tracking and recovery semantics. Regulated products need an owned transaction state machine.
Where does the custodian fit?
Signing and custody policy enforcement. Application authorization should decide whether an operation is allowed before a signing request is created. See custody integration.
Does this run in our cloud?
Yes by default. Customer-hosted single tenant keeps transaction state and credentials in your infrastructure.
What this module owns
Does not own
- business authorisation — it is handed signed bytes, not a decision
- custody policy and approval flows
- customer IAM
- what an operation means
Technical surface
The engine accepts signed bytes, a gas budget and a nonce. It holds no role that would let it interpret them, which is why the surface is this narrow.
- POST /v1/transactions
- GET /v1/transactions
- GET /v1/transactions/{id}
Every mutating call carries an Idempotency-Key and returns an operation that is polled to a terminal state, so a retry returns the original operation instead of issuing a second one. Rejections before signing, conflicts and reverted executions are distinct failures rather than one generic error. The full schema is served as OpenAPI by the deployment itself.
Deployed as a container image with a Helm chart and Terraform modules, single-tenant in your own cloud account, against a PostgreSQL database you hold — see the deployment model.
Related
The durable path from decision to confirmation
Show us the operations your product must execute on-chain. We can map the durable path.
Discuss your architecture