Customer backend may own
Subscription, documents, signed state, payment, approval, suitability and other customer-specific workflow — everything before the investment becomes effective.
Product module
Investment ledger for tokenized ownership
Effective tokenized investments — FIFO lineage, ownership transfers, reallocations, redemptions and reconciliation against on-chain balances.
An Investment in Tokenistry means the position is now effective and counts toward tokenized ownership. It is not the customer’s full subscription workflow.
A blockchain indexer can report that wallet X received 50 tokens. The Investment Ledger can explain that investor B received 50 units through an ownership transfer, allocated via FIFO from a prior investment, with preserved lineage.
Where your workflow ends and the ledger begins
Tokenistry owns
Investment, amount, remaining amount, position, FIFO, lineage, ownership transfer, reallocation, redemption, issuance linkage, burn linkage, ownership history and reconciliation against chain state.
investment.effective
Customer Backend
POST /investments
Tokenistry Investment Ledger
What the ledger tracks
- effective investments
- amount / remaining amount
- positions
- FIFO allocation
- investment lineage
- ownership transfers
- reallocations
- redemptions
- issuance / burn linkage
- ownership history
- on-chain reconciliation
Ownership transfer
Investor changes: Investor A → Investor B. The ledger applies FIFO against A’s effective investments and creates resulting investment lineage for B.
investment.ownership transfer
Investor A
FIFO
Investor B + lineage
Reallocation
Investor stays the same: Wallet 1 → Wallet 2. Ownership does not change — only the holding location moves.
investment.reallocation
Wallet 1
Wallet 2
Redemption
Ownership is reduced and linked to burn or redemption. Remaining amount and position update so the ledger stays aligned with token supply changes.
investment.redemption
Effective Investment
Redemption
Burn linkage
FIFO example
A owns Investment #1 = 100 and Investment #2 = 200. A transfers 150 to B. FIFO consumes 100 from #1 and 50 from #2, producing B’s Investment #3 = 100 ← #1 and Investment #4 = 50 ← #2.
investment.fifo.example
A owns Investment #1 = 100 Investment #2 = 200 A transfers 150 → B FIFO consume 100 from #1 50 from #2 Result B Investment #3 = 100 ← #1 B Investment #4 = 50 ← #2 A remaining Investment #1 = 0 Investment #2 = 150
Your references, carried not interpreted
Customer references can travel in metadata. Tokenistry stores them but does not interpret arbitrary workflow fields.
investment.metadata
{
"metadata": {
"subscription_id": "sub_8f2a…",
"contract_id": "ctr_91c0…"
}
Reconciliation
Sum of effective investment positions must equal on-chain balance. The Indexing Engine supplies observed state; the Investment Ledger owns reconciliation logic.
ownership.check
Σ Effective Positions
On-Chain Balance
FAQ
Is this a full subscription and payment system?
No. An Investment means the position is now effective and counts toward tokenized ownership. Subscription, documents, signed state, payment, approval, suitability and customer-specific workflow stay in the customer backend until effectiveness.
What is the difference between an ownership transfer and a reallocation?
Ownership transfer changes the investor (A → B) and creates FIFO lineage for B. Reallocation keeps the same investor and only changes wallet (Wallet 1 → Wallet 2); ownership does not change.
How is this different from the Indexing Engine?
The Indexing Engine supplies observed on-chain state. The Investment Ledger assigns business meaning — ownership lineage, FIFO consumption, positions — and owns reconciliation against that observed state.
What about customer-specific references?
External IDs such as subscription_id or contract_id can live in metadata JSON. Tokenistry stores them but does not interpret arbitrary customer workflow fields.
How does redemption relate to burn?
Redemption reduces ownership on the ledger and is linked to burn/redemption so remaining amounts and positions stay aligned with token supply changes.
What this module owns
Owns
- effective ownership and FIFO lineage
- ownership transfers, reallocations and redemptions
- reconciliation against indexed chain state
- anomalies where the two disagree
Does not own
- the subscription workflow before an investment is effective
- payment, documents or approval state
- wallet custody
- the chain's own balances
Technical surface
Investors, wallet assignments and asset positions are separate resources. Assigning a wallet after the fact replays the positions it affects rather than requiring a manual repair.
- GET /v1/investors
- POST /v1/investors
- GET /v1/assignments
- POST /v1/assignments
- DELETE /v1/assignments/{id}
- GET /v1/assets
- GET /v1/assets/{id}/status
- GET /v1/assets/{id}/lots
- GET /v1/assets/{id}/anomalies
- GET /v1/assets/{id}/positions/investors/{id}
- POST /v1/catalog/sync
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
A canonical ledger between your product and the chain
Show us how investments become effective today. We can map the Tokenistry ledger boundary.
Discuss your architecture