Physical commodities in custody are the collateral class that ledger projects keep skipping. They are hard because the asset cannot be tokenized without lying about where it is. So I built the other thing: a specification for registering who may do what with the asset, and when that changed, and implemented it on more than one ledger to see which architectures can carry it.
Title stays with the owner. Possession stays with the custodian. Only the signed control lifecycle goes on the ledger.
Most real-asset work starts by issuing a token that claims to represent the thing. That works reasonably for cash flows and badly for physical goods, because the token and the metal can part company the moment anything goes wrong, and the party holding the metal was never a signatory to the token.
Banks lend against warehoused commodities today. What they do not have is a shared, replayable record of the control lifecycle: who selected the lot, who immobilized it, who approved the substitution, when the cure window opened, and which document each act was made against. That record is the part a ledger is genuinely good at, and it is the part nobody built.
Three parties define a control perimeter: the owner who keeps title, the custodian who keeps possession, the bank that lends. The specification fixes the acts they may perform, the order they must perform them in, and the record each act leaves behind. It says nothing about any particular ledger.
From registering the framework and the attested lot, through pledge, drawdown, revaluation and substitution, to default, cure and enforcement. Each act names one authorizing role and one state transition.
The rules that make it the protocol rather than a workflow. Substitution moves owner, then custodian, then bank, and never skips. A cure binds the bank that declared the default, and the bank cannot enforce before the deadline it set. No release while anything is drawn. A lot pledged once cannot be pledged again.
Read only the evidence records, fold them in sequence, and arrive at exactly the state the ledger holds. State guards execution. The record set reconstructs the evidence. If the two disagree, the implementation is wrong.
The same specification, carried onto architectures that disagree with each other about privacy, events and time. That disagreement is the research.
Soroban and Canton both make issuing an asset easy, and both make modelling control without issuing one the deliberate harder path. The design pressure runs toward tokenizing the metal, which is the exact thing that must not happen. Resisting that is an architectural decision taken on the first day, not a policy written afterwards.
A transaction log is not an audit record. Reconstructing a collateral position needs the act, the authorizing role, the state transition, and the document each was made against, sequenced without gaps and scoped to the deal. Every ledger gives you some of that and no ledger gives you all of it.
The same contract puts a party in a completely different reporting position depending on the ledger underneath. Publish commitments to everyone and any party can reconstruct the record. Disclose per participant and the question becomes whether any single party can produce a complete one, which is what a collateral reporting obligation actually demands. This is the axis worth measuring, and it is the reason to build more than one.
PhD candidate at Sofia University St. Kliment Ohridski, Faculty of Mathematics and Informatics, on modelling smart contracts and blockchain governance. Earlier work runs on physical and real-world assets rather than securities.
Physical collateral is the case that gets left out of the roadmap, and I am interested in how each architecture handles it specifically. If you work on product for one of these platforms, the questions I bring are concrete: how state and events change across the control lifecycle, how each change is disclosed to each counterparty, and where the domain logic for a real-world asset should sit.