Architecture assessment

What to build, what to buy, and what stays in your account.

A tokenization stack has a few parts worth writing yourself and a great many that have been written before. This page is about drawing that line for your case: which layers your customers can actually tell apart, which ones you would be re-deriving at your own cost, where key authority and control boundaries have to sit, and how much of Tokenistry a given scope really requires. It is a decision page — for how the modules behave once the decision is made, see technology.

Request an architecture review What a review produces

The line between product and infrastructure

The useful question is not which components exist but which of them a customer could ever choose you for. Everything above that line is worth your engineers. Everything below it is identical across every issuer who has built it, which is precisely what makes it a poor use of a team that could be shipping the part nobody else has.

architecture // where each layer belongs
Layer	Who should own it	Reasoning
Investor experience, subscription, documents, payments	You	This is the product. It carries your commercial model and it is the only layer a customer experiences directly. Nothing here is reusable, and nothing here should be bought.
Issuer and back-office workflows	You, mostly	Specific to how you run an issuance and how your operations team is structured. Buying it means adopting someone else's operating model by accident.
Eligibility decisions — KYC, AML, classification, jurisdiction	You or your regulated vendors	Whether an investor may hold is a regulated judgment with an accountable owner. Software should consume that decision, never make it. Infrastructure's job starts once the answer exists.
Ownership arithmetic — lots, FIFO consumption, lineage	Buy	Deterministic, identical across issuers, and the failure mode is silent: a position that is wrong but plausible. This is the layer where reusable, heavily exercised logic is worth the most and shows the least.
Transaction orchestration — queue, signing, nonces, confirmation	Buy	No customer will ever pick you for it, and it takes the longest to make dependable. The happy path is two weeks; the failure paths are the program.
Chain ingestion, normalization, reorg handling	Buy	Same shape as above, with the added cost that it is never finished — providers change, chains fork, and the code has to keep pace whether or not you are shipping features.
Token contracts and on-chain transfer restriction	Buy the implementation, hold the authority	Standards exist and bespoke contracts are risk without differentiation. What must not be delegated is the admin and upgrade authority over deployed tokens.
Chain, RPC and signing adapters	Neither — it should be invisible	Not a product and not worth a team. Adapters exist so the layers above them are chain-agnostic, which is what makes a second network an adapter rather than a rewrite.
Keys, database, cloud account, RPC credentials	You, without exception	These are the assets your control framework already covers. A vendor holding any of them converts a software decision into a counterparty exposure.

What building it actually commits you to

Build-versus-buy goes wrong when the estimate is made against the demo. Issuing a token and moving it between two wallets is two weeks' work and it convinces everyone in the room. The commitment being made is to everything after that: an operation that must settle exactly once however many times it is retried, nonces that stay correct while several workers submit concurrently, indexed state that retracts cleanly when a block is reorganized, and ownership that reconciles against the chain rather than drifting quietly away from it.

None of that is exotic, and that is rather the point — it is well-understood work that simply has to be done carefully, which makes it expensive in exactly the way that is hard to justify in a roadmap. It is also permanent: chains fork, providers degrade, standards move, and the team that owns this layer is never released from it. The failure behavior on the technology page is a reasonable specification to hold any build to, including your own.

A test worth applying before committing. Take the layer you are planning to build and ask what happens on the day your RPC provider starts rate-limiting mid-issuance, or a worker is rescheduled between signing a transaction and seeing its receipt. If the answer is a design discussion rather than a behavior somebody can describe, the estimate is for the demo rather than the system.

Custody and key boundaries

The question is not whether you trust a vendor. It is which process is able to produce a signature, and what that signature is able to authorize. Those two answers determine your blast radius, and they are worth settling before anything is deployed, because they are expensive to change afterwards.

Two key roles, deliberately separated

Token authority — mint, burn, freeze, forced transfer, roles. Compromise here moves investor assets.
Gas payers — fund and submit transactions. Compromise here costs money and nothing else.

These must not sit in the same process. In Tokenistry Core the Tokenization Engine holds the authority key and the Transaction Engine holds gas-payer keys, and neither is able to read the other's. Whatever you build or buy, insist on that split: a relayer that can also freeze an investor is an incident waiting for a cause.

Where the signature is produced

In both engines signing sits behind an interface, so which backend holds a key is a deployment decision rather than a rewrite. That is the property to insist on: a stack that hard-codes a local key has decided your custody model for you.

Gas payers — an AWS KMS signer is implemented and selected by configuration. It is a build-time option that released images are not currently compiled with, so using it means a build that enables it.
Token authority — the same interface, with no external backend behind it yet. What ships is an encrypted keystore, unlocked with a passphrase from your secret manager.
Tokenistry as a company holds no customer keys and has no path into a production deployment.
Contract admin and upgrade authority are yours, so no vendor release can alter a deployed token.

Note the asymmetry, because it is the wrong way round: the key that can only spend gas is the one that can already be externalized, while the key that can freeze or move an investor's position is the one still held in process. If your control framework requires that key to be non-exportable, treat it as scoped work with a known shape — the seam exists — and price it in the assessment rather than assuming a flag.

Compliance and transaction architecture

Two decisions here tend to be made implicitly and then become structural. Both are worth making on purpose.

Where enforcement lives

A permission check in the application in front of the token is only as good as the guarantee that every transfer goes through that application — a guarantee that erodes the moment a back-office tool, a migration script or a later integration needs direct access. A restriction enforced inside the token applies to every transfer regardless of who initiated it.

The cost is real and should be priced rather than waved through: on-chain enforcement means a registry to keep synchronized and a governed upgrade path for the contract logic. That is a smaller problem than an unenforceable rule, but it is not nothing.

Where the decision is made

Eligibility is a judgment your KYC, AML and classification systems own, with a named accountable party behind it. Infrastructure's job is to turn that judgment into on-chain permission and keep the two synchronized — never to encode jurisdiction logic in a token where changing it is a deployment.

The invariant that matters: permission should be derived from current eligibility relationships rather than accumulated from historical grant and revoke commands. If an investor qualifies through two routes, losing one must not silently revoke access still granted by the other.

Synchronous calls are the retrofit you cannot afford

Chain latency is unbounded and confirmation is revocable until finality. Any user-facing flow written as a synchronous call into a chain will work in testing and fail in production, and converting it later is a rewrite of everything built on top.

Decide early that business operations are durable records with lifecycle state, and that the chain is something they reconcile against rather than something they wait on. That single choice determines whether reliability is a property of the design or a permanent source of incidents.

Deployment and control boundaries

Multi-tenant infrastructure is a reasonable default in most of software and a poor one here, because the things it would hold — signing keys, investor data, the ownership ledger — are exactly the things your regulator, your auditor and your board already have a framework for. Single-tenant deployment into your own cloud account is not a hardening measure; it is what keeps the vendor out of your regulatory surface entirely.

Stays in your account, always

signing keys and the secret manager holding their passphrases
investor data and the ownership ledger database
RPC credentials and any custody workspace
backups, retention, IAM and network policy

The question to ask any vendor

If this vendor is unreachable tomorrow — outage, dispute, acquisition, insolvency — what stops? If the honest answer includes settlement, investor access or your ability to read your own ownership records, the boundary is in the wrong place, and no contractual term repairs it.

For Tokenistry the answer is that nothing stops: there is no vendor control plane in the data path, no inbound access into a production deployment, and license validation is an offline signature check rather than a call home. That claim is worth demanding from anyone, and worth testing rather than accepting.

Which modules a given scope actually needs

Buying all five is usually the wrong answer, and the most useful outcome of an assessment is often a shorter list than the one it started with. Scope drives selection.

architecture // module selection by scope
If your scope is	You need	Notes
Issue and administer tokens, operator-driven, low volume	Tokenization Engine	Stands alone, and includes the contract suite, the compliance registry and the transfer controls. For many first deployments this is the whole purchase.
Investor-facing flows, volume, retries, confirmation tracking	+ Transaction Engine	Worth separating once submission stops being something an operator can watch. Below that threshold it is complexity you are not yet using.
Positions, history or chain state surfaced inside your product	+ Indexing Engine	Normalized chain state that other modules read, so each one is not polling the chain and deriving its own view of it.
Effective ownership, lots, lineage, redemptions, reconciliation	+ Investment Ledger	Depends on indexed chain state and is deployed together with the Indexing Engine. This is the module carrying the most reusable domain logic.
Who may hold, across many tokens and investor relationships	Eligibility & Whitelisting	Contract-level lists and per-transfer enforcement ship inside the Tokenization Engine today. The pool model — many-to-many eligibility with derived permission and synchronization workers — is roadmap rather than shipping, and is scoped as co-funded build.

What this layer does not cover

Stated plainly, because discovering it during implementation is expensive and discovering it during an audit is worse.

Not in the infrastructure

KYC, AML and investor classification — decided by your systems or vendors
payments, fiat movement and settlement of cash legs
investor onboarding, documents and CRM
legal structuring and regulatory advice of any kind
acting as your custodian or holding assets on your behalf

Not shipping today

non-EVM networks — EVM chains only, further networks are adapter work driven by an engagement
external signing for the token authority key — the interface exists, the backend does not; KMS signing for gas payers is implemented but not compiled into released images
the eligibility pool model, as described above
an external smart-contract audit — the contracts are tested extensively but not third-party audited

Anything in the right-hand column is scoped and priced work rather than a switch, and it belongs in the assessment where it can be costed against your timeline. A vendor who answers every capability question with yes is describing a roadmap, not a deployment.

What an architecture review produces

A written deliverable rather than a proposal, and deliberately separable from any license — it is worth doing on its own if the conclusion is that you build, or that you need less than you came in expecting.

a boundary map of your intended stack, layer by layer
a build, buy or defer recommendation for each layer, with reasoning
key topology: which process signs what, and the blast radius of each
deployment and control model against your existing cloud and IAM
module selection, including what you do not need
gaps that are scoped work rather than configuration, named as such
where dedicated engineering capacity still adds value
the parts of the decision that are reversible, and the parts that are not

FAQ

We already have a blockchain team. What is left to buy?

Usually the least visible parts. A team that can write a token contract and submit a transaction has covered the work that demonstrates well; what takes the longest to make dependable is the submission path under concurrency and failure, reorg-safe ingestion, and ownership arithmetic that reconciles against the chain rather than drifting from it. Those are identical across issuers, which is what makes them worth reusing. Keep your team on the parts a customer can actually tell apart.

Can we start with one module and add others later?

Yes, and most engagements do. The Tokenization Engine stands alone. The Investment Ledger depends on indexed chain state, so it is taken together with the Indexing Engine. The Transaction Engine becomes worth its own deployment when submission volume, retries and confirmation tracking stop being something an operator can watch. Module selection is part of the assessment, and the useful outcome is often a shorter list than the one you arrived with.

Do you recommend multi-tenant SaaS for transaction and custody data?

Not as an initial architecture. Single-tenant in your own cloud account keeps investor data, the ledger database, RPC credentials and signing keys inside a boundary you already have a control framework for, and it removes the vendor from your regulatory surface. The test worth applying to any vendor, including us: if they are unreachable tomorrow, what stops? If the answer includes settlement or investor access, the boundary is in the wrong place.

Is this a consulting engagement or a software purchase?

The assessment is a paid engagement with a written deliverable, and it is deliberately separable from any license. It is worth doing on its own if the outcome is that you build, or that you need less than you expected. Where modules do fit, the assessment is what determines which ones and how they are deployed.

What happens if we want to leave?

The token, its holders and its eligibility state are on chain, and the contracts' admin and upgrade authorities are held by you, so the asset itself does not depend on the backend that orchestrates it. Ledger and indexed state are in your own PostgreSQL instance under your backups. What you would be rebuilding is the orchestration layer, which is the honest cost of the decision and worth pricing before you commit rather than after.

Bring the decision, not the requirements document

The most useful first conversation is about what you are planning to build and what you have already committed to. If the outcome is that you should build it yourself, that is a finding worth having early rather than a deal lost late.

Request an architecture review