Integration capability
Custody integration for production tokenization systems
Custody integration is an implementation capability, not a Tokenistry Core product module. Your custodian provides key material, signing, policies and authorization. Tokenistry supplies the domain operation, transaction orchestration, investment state, compliance logic and DLT state handling around that path — in your environment.
Keys stay where they already are. The Transaction Engine builds the transaction, hands it to a custody adapter for signature and picks the signed result back up — so what sits behind that interface, whether an institutional custodian, an MPC or HSM setup, a cloud KMS or an encrypted keystore you operate yourself, is a deployment decision rather than an architectural one.
That boundary is deliberate. Custody is the part of a tokenization stack most likely to be already chosen, contractually committed, or changed under you. Naming one provider in the architecture makes a migration a rewrite; naming an interface makes it a configuration change. Fireblocks is one adapter behind that interface, not the shape of it.
What the adapter owns
The same surface for every provider. An adapter maps a custodian's API onto it; nothing above the interface changes when the custodian does.
- vault / wallet mapping
- signing request lifecycle
- transaction authorization
- approval and policy waits
- typed-data (EIP-712) signing
- status and error mapping
- application permission boundaries
- failure and retry semantics
Supported today: encrypted keystore and cloud KMS for customer-operated keys. Institutional custodians — Fireblocks among them — are integrated per engagement against this interface. Nothing here is a partnership or certification claim.
Customer-controlled custody boundary
control plane
Default deployment keeps custody credentials, policies and accounts in your control. Tokenistry supplies the reusable integration and orchestration layer — not a shared multi-tenant signing plane for all customers.
The stack separates the account that holds contract roles from the account that pays gas: they are different keys, in different services, with different databases. Either one alone moves nobody's tokens. That separation holds whichever custody backend sits behind the interface.
See customer ownership and Transaction Engine.
FAQ
What still needs custom engineering around a custodian?
Business workflow, compliance decisions, application state, transaction orchestration, idempotency, reconciliation, monitoring and failure handling. A custodian addresses key management and signing; the surrounding production system still has to be designed.
Are you a partner of any custody provider?
No. Tokenistry has engineering experience with institutional custody platforms including Fireblocks, and that should not be read as a partnership, certification or reseller claim. The adapter interface exists precisely so the choice stays yours.
We already run our own signing. Does this force a custodian on us?
No. Customer-operated keys behind an encrypted keystore or cloud KMS are a supported configuration, not a fallback. Whether institutional custody is worth its cost depends on key-management requirements, operational controls, policy needs and risk posture — that question belongs in the architecture assessment, not in the software.
Technical surface
Custody has no public Tokenistry API. It sits behind the Transaction Engine as an internal interface with one adapter per provider, which is what keeps the provider replaceable and keeps the domain modules from learning a vendor's vocabulary. Your product calls the Transaction Engine; the workspace, the policies and the approval flow stay yours.
Deployed as a container image with a Helm chart and Terraform modules, single-tenant in your own cloud account — see the deployment model.
Related
Institutional custody, behind one interface
We can map signing policies, application authorization and the transaction path around the custodian you already use.
Discuss your architecture