I.

The claim is not that assets should be programmable. They already are, and programmability alone points the wrong way. An ERC-20 token can execute arbitrary code, yet that code has no structured relationship to the legal requirements governing the token. A Solidity function can consult a sanctions list, but the consultation is application logic standing beside the transfer: nothing in the architecture ensures that the check ran, that it ran against the current list, or that its result was kept as evidence.

The security-token standards repaired part of this. ERC-1400, ERC-1404, and ERC-3643 build the compliance check into the token contract itself: a transfer executes only if the token’s own restriction check permits it – a status code in ERC-1400, two view functions in ERC-1404, an identity registry and a modular compliance contract in ERC-3643 – so for the transfers those standards govern, on the one ledger where the token lives, the check cannot be skipped. What the check returns is thin – permit or refuse, with a reason code – and what it leaves behind is thinner. The jurisdiction is fixed in the deployment rather than a parameter of the question. A refused transfer leaves at most a reason code, with no record of what was evaluated or against which compliance state; a permitted one leaves a state change, with no evidence of what was evaluated to permit it.

A smart asset, in the sense meant here, closes the remaining distance. It is an asset that carries a compliance program as a structural component, as fundamental as its ownership record. When the asset is examined, the examiner can verify ownership, confirm for every recorded lifecycle event that every governing rule was evaluated – in the jurisdiction and at the moment of that event – and inspect the evidence, failures included.

This calls for a domain-specific virtual machine, and its mechanisms are old. Gas-metered termination is the EVM’s own device (Wood 2014). Hash-chained tamper-evident records date to Haber and Stornetta (1991) and run at internet scale in Certificate Transparency (Laurie, Langley and Kasper 2013). Routing every privileged operation through one checked boundary is the complete-mediation principle of Saltzer and Schroeder (1975). The contribution is the composition: an interpreter in which compliance evaluation is an instruction returning a typed verdict, every execution leaves a chained receipt, state changes with institutional consequences are requests rather than actions, and an execution can suspend for human approval. The rest of this paper specifies that machine and states exactly what its evidence proves, and to whom.

II.

Consider what happens when a corporation issues shares. The issuance requires board authorization. Depending on the jurisdiction, it may require shareholder approval above a threshold. The shares must comply with securities regulation. The recipients must pass KYC and sanctions screening. If the shares are offered across borders, further compliance domains activate. Tax treatment varies by jurisdiction.

In a conventional system these requirements are checked by separate systems at separate times, and the results land in separate databases. The share records none of it. Six months later, when the shares are transferred, the compliance context is reconstructed from scratch.

Now suppose the share carries a program. The program encodes the compliance requirements that applied at issuance. When the share was created, the program ran: it read the compliance state of the issuing entity across the relevant domains – sanctions, securities, corporate governance, tax – and verified that every domain was satisfactory. It produced a receipt: a cryptographic record of what was checked, what the results were, and what the compliance state looked like at that moment, bound to the share’s identity.

When the share moves, the program runs again, in a context with a different jurisdiction, a different holder, and a different moment in time. It evaluates the domains relevant to that context and produces another receipt, chained to the previous one. The share accumulates a verifiable history: ownership, timing, and the compliance evaluations performed at every lifecycle event at which the program ran.

The word “smart” has meant self-executing at least since Szabo (1997) proposed embedding contractual terms in code. For institutional assets the useful sense is stricter: the asset carries its compliance program, the program runs at every lifecycle event, and every run leaves evidence.

III.

The virtual machine that runs these programs differs from a general-purpose runtime in three ways.

First, compliance evaluation is a primitive operation. The machine’s state of reference is the institution’s compliance state, indexed by entity, jurisdiction, and domain. One instruction reads a cell – the standing of this entity, in this jurisdiction, in this domain – and returns one of five verdicts: compliant, pending, exempt, not applicable, or non-compliant. The five stay distinct because they are distinct facts: a pending review and an exemption may both permit an action today, and collapsing either into “allowed” destroys exactly the distinction an examiner later needs. In the EVM the equivalent read requires an oracle, and the difference is not that an oracle indirects – this instruction also crosses a boundary, out of the VM and into the institution’s compliance infrastructure, and trusts the answer it receives. The difference is that the crossing is a typed primitive rather than application logic: the machine, not the program’s author, fixes the verdict type, prices the read, and mandates into the receipt that the read happened, what it asked, what was answered, and the digest of the evidence behind the answer.

Second, writes are deferred, never immediate. When a program determines that a corporate action is needed – an ownership transfer requires a treasury update, say – it cannot perform the write. It produces a request: this write should happen. The request is collected in the execution receipt and handed to the institutional write pipeline, which applies its own authorization, sanctions screening, and audit logging before deciding whether to execute. The VM can conclude; only the institution can act.

Third, every execution produces a receipt, failures included. A program that runs out of gas leaves a receipt saying so. A program that reverts because a compliance domain failed leaves a receipt naming the domain and its verdict. A program that succeeds leaves a receipt itemizing every compliance evaluation, every storage mutation, and every deferred write request. Receipts chain: each binds the digest of its predecessor, so the asset’s recorded execution history is tamper-evident. Section VI states what that chain proves, what it does not, and under which commitments.

IV.

Gas serves two purposes here, and termination is the hard requirement. An asset’s program runs inside institutional processes that cannot wait: a transfer agent, a registry, a settlement deadline. A compliance check that could run forever would let a hostile program detain every system obliged to process the asset. Termination follows from one stated assumption: every instruction that can be followed by another instruction costs at least c > 0 gas; only the terminal instructions – halt, return, revert, yield – are free. Under that assumption, an execution with budget G executes at most G/c + 1 instructions. In the schedule below, c = 2 and G = 10,000,000, so every execution ends within 5,000,001 instructions. The bound is per execution. A yielded program resumes on quorum as a new execution with a fresh budget, and nothing bounds how many times a program may yield, so the lifecycle as a whole obeys a weaker statement, which this bound and the approval deadline of Section VI give together: every execution ends within its budget, every suspension ends within its deadline, and a lifecycle with finitely many suspensions terminates. Indefinite prolongation requires a fresh quorum at every round, each round bounded by its own deadline; it is a sequence of recorded decisions by the approvers, and it detains nothing, because each execution has already ended.

The second purpose is pricing. The schedule is tiered; its representative prices:

The budget for one execution is 10,000,000.

The schedule prices two scarce resources at once, and is therefore monotone in neither alone. Machine effort explains the lower tiers, and explains why zero-knowledge verification – pure computation – costs five times a compliance read. Institutional attention explains the top of the table: a compliance read crosses into the institution’s compliance infrastructure, and an institutional write request asks the institution to evaluate and possibly fulfill a mutation, priced at ten reads.

Because every price is nonnegative, the price of one institutional operation is a lower bound on the total of any execution that performs it, and the meter is a one-sided certificate. A total below 10,000 proves the program performed no compliance read and requested no institutional write. A total below 100,000 proves it requested no write. In the other direction the total discriminates nothing – 5,000,000 gas is equally five hundred compliance reads or fifty write requests – which is why the meter is a bound and a summary, and the receipt is the record of what actually ran.

V.

The architecture separates into two levels.

Level 1 is compliance enforcement. These programs are compiled from the asset’s declared compliance requirements: an asset that declares sanctions clearance and securities compliance gets a program that reads those domains and reverts unless every verdict permits the action. Level 1 programs are bound to the asset by content digest, and the digests are declared in the asset’s identity, so an examiner can later check that the programs that ran are the programs the asset declares. They are part of what the asset is, not something applied to it from outside.

Level 2 is programmable logic: user-authored programs that run after Level 1 has verified the compliance context. A Level 2 program can read compliance state, write its own storage, emit deferred write requests, and compute arbitrarily within its budget.

Neither level can write compliance state. The instruction set contains no operation that modifies the compliance state. A program whose logic concludes that compliance state should change – it has assembled the evidence of a completed review, say – requests the change as a deferred write, priced at the write tier and judged by the institutional write pipeline like every other institutional mutation. Level 1 programs run with deferred writes disabled altogether: a gate can read and it can revert, nothing else. The attack in which a program manipulates compliance state and then passes its own checks is closed by the instruction set, not by convention: within an execution there is no write to read back.

The ordering of the levels is enforced by the composition root – the host process that invokes the VM – which runs every Level 1 program and proceeds to Level 2 only if all of them succeed. That is a property of the host, not of the VM, so the design makes it checkable rather than merely promised: a Level 2 receipt carries the digests of the Level 1 receipts produced for the same invocation. An examiner reading the chain verifies not only that the gates passed but that they passed first, and a Level 2 receipt without its gate receipts is, on its face, evidence of circumvention.

VI.

The receipt chain is what makes the construction verifiable, and the party to design against is the operator: whoever runs the executions, stores the chain, and might prefer a different history.

Every execution – every run of any of the asset’s programs, for any reason – produces a receipt. The receipt records the execution digest, a hash binding the program’s bytecode digest, the caller, the jurisdiction, the timestamp, the sequence number, and the digest of the previous receipt; the outcome – success, revert with its reason, a resource-limit halt, or yield; the gas consumed; every compliance evaluation, with its domain, context, verdict, and the digest of the evidence behind the verdict; every storage mutation as a before-and-after pair; every deferred write request; and every log entry. The receipt’s own digest covers all of it, and the next receipt binds that digest, so altering, deleting, or reordering any interior receipt breaks every digest above it.

A hash chain alone, though, proves only self-consistency. The operator who produced it could produce a different chain from scratch, correctly linked, and nothing internal to the two chains would distinguish them. The chain becomes evidence through two commitments. Each receipt is signed by the operator that produced it, which makes the history attributable: the operator cannot disown what it recorded. And the head of the chain is periodically committed outside the operator’s control – handed to the counterparty of the transaction it covers, filed with the jurisdiction’s registry, or anchored in a public log. Once a head is in other hands, every receipt beneath it is fixed: a rewrite cannot reproduce the committed digest.

An examiner holding a committed head can then verify the chain without trusting the operator’s storage: recompute each receipt’s digest from its content; follow the predecessor links and strictly increasing sequence numbers up to the committed head; check the signatures; and check that the program digests inside the execution digests match the compliance programs the asset declares. What survives this check is integrity, order, and attribution: these executions ran, in this order, under these programs, and the operator has signed to it. Three residues remain, and they should be named. Receipts newer than the latest committed head are not yet fixed, so the commitment interval is the operator’s window for revision – setting that interval is a policy decision. A receipt proves what was evaluated and what the compliance infrastructure answered – the evidence digests identify exactly which list, filing, or record the answer relied on – not that the answer was true; the correctness of the sanctions list itself is vouched for by the list’s provenance, not by this chain. And the chain proves the executions it records, not that every event requiring one was recorded: a lifecycle event the operator handles outside the machine leaves no receipt and breaks no digest. Certificate Transparency carries the same residue and closes it the same way – a log proves only what was logged, so the relying party refuses what is not logged – and here the relying party is the counterparty. A counterparty that completes a transfer only against a committed head covering it holds the proof that the transfer was recorded, and no transfer completed on those terms can have run outside the machine. The closure is per transaction, and an event with no party outside the operator to demand a head for it keeps the residue.

One case remains: execution that cannot complete in one step. Some institutional workflows require human approval – a board vote, a regulatory sign-off. When a program reaches a multi-party approval gate, it yields: the execution ends with a receipt recording the required approvers, the threshold, and a deadline. Approvals accumulate against the requirement. Quorum resumes the program as a new execution with a fresh budget; if the deadline passes first, the suspension closes with a receipt recording the expiry and the program does not resume. Every suspension therefore resolves within its deadline, and either way the governance process that interrupted execution – however many days it took – appears in the chain, from suspension to resolution.

VII.

The separation between the asset and the rules governing the asset is an artifact of how financial infrastructure was built, not of what an asset is. A share is a legal instrument that exists inside a compliance context, and the context is as much a part of the share as its par value or its ownership record. The machine described here makes the context part of the instrument: requirements compiled into gate programs bound to the asset’s identity, evaluation at every lifecycle event, a receipt for every evaluation, and a chain whose history is fixed in hands other than the operator’s.

Limitations

The machine evaluates compliance; it does not decide it. Verdicts come from the institution’s compliance infrastructure, and the chain proves what was asked and answered, never that the answers were right. The compilation of declared requirements into Level 1 programs is likewise assumed faithful: a wrong gate program produces wrong gating with complete evidence, because the chain proves fidelity to the program, not the program’s fidelity to the law. The chain proves the executions it records, not that every event requiring one was recorded; an event the operator handles outside the machine leaves no trace in it, and the omission closes only per transaction, through a counterparty that completes its transaction against a committed head covering it. The termination bound is per execution: every suspension resolves within its deadline, and a lifecycle terminates given finitely many suspensions; approvers who grant fresh quorum at every round can prolong it without bound, each round bounded by its own deadline. The evidentiary guarantees are relative to the commitments: operator signatures assume the provenance of the signing keys, and everything after the newest committed head remains revisable until the next commitment. Finally, the machine computes and requests; only the institution acts. A Level 2 program can compute a coupon or a redemption, and what leaves the machine is a deferred write request that the institution’s pipeline settles or refuses: the boundary of Section III, not a limit on what the program computes.

References

Dossa, A., Ruiz, P., Vogelsteller, F. and Gosselin, S. (2018). ERC-1400: Security Token Standard. Ethereum improvement proposal 1400.

Haber, S. and Stornetta, W. S. (1991). “How to Time-Stamp a Digital Document.” Journal of Cryptology 3(2), 99–111.

Laurie, B., Langley, A. and Kasper, E. (2013). Certificate Transparency. RFC 6962, IETF.

Lebrun, J., Malghem, T., Thizy, K., Falempin, L. and Boudjemaa, A. (2021). ERC-3643: T-REX – Token for Regulated EXchanges. Ethereum improvement proposal 3643.

Saltzer, J. H. and Schroeder, M. D. (1975). “The Protection of Information in Computer Systems.” Proceedings of the IEEE 63(9), 1278–1308.

Szabo, N. (1997). “Formalizing and Securing Relationships on Public Networks.” First Monday 2(9).

TokenSoft (2018). ERC-1404: Simple Restricted Token Standard. Ethereum improvement proposal 1404.

Wood, G. (2014). Ethereum: A Secure Decentralised Generalised Transaction Ledger. Ethereum yellow paper.