How the Debt Algorand Standard Application (D-ASA) - awarded 2nd place in the global ACTUS Competition 2026 - turns the financial industry's contract standard into machine-readable and executable, tokenized debt instruments, and why that should change how banks, payment agents, and transfer agents look at the AVM.
Debt is one of the largest asset classes on the planet. And every debt instrument - every bond, loan, mortgage, and term deposit - is, at its core, a deterministic promise for the exchange of future cashflows: these amounts, on these dates, to these parties, under these conventions.
Yet the operational reality of that promise is anything but deterministic. The lifecycle of a single bond is scattered across the issuer's books, the paying agent's systems, the transfer agent's registry, custodians' ledgers, and the CSD - each holding its own copy of the truth, each reconciling against the others, forever. The contract is an algorithm; the operations around it are documents, spreadsheets, and settlement queues.
Two things had to happen for that to change; one belongs to the finance standards, the other belongs to the technology. The first already did: ACTUS open standard made financial contracts machine-readable. The second is what this post is about: the Algorand Virtual Machine (AVM) makes them machine-executable.
This is precisely what D-ASA - the Debt Algorand Standard Application sets out to explore: a personal side-project and proof-of-concept tokenization framework for ACTUS-compliant debt instruments issued and executed on the AVM, recently awarded second place in the 2026 global ACTUS competition promoted by the ACTUS Foundation. This post walks through what it demonstrates, how it touches on the entire debt value chain (issuance, KYC, primary distribution, secondary trading, payments, oversight), and why the design choices (asynchronous settlement trackers, native atomic DvP, post-quantum-secured history) map so naturally onto how regulated finance actually operates.
ACTUS: financial contracts as algorithms
If you work in traditional finance, you may already know ACTUS (Algorithmic Contract Types Unified Standards). Born out of the post-2008 push to make financial risk transparent and computable, ACTUS reduces most financial contracts to a defined taxonomy of 32 generalized cash-flow exchange patterns, called contract types. ACTUS “discovers” and formalizes the fundamental “notes” that compose any “financial symphony”.
The insight behind ACTUS is simple and profound: a financial contract is not prose; it is a function. Feed it a set of contract attributes (principal, rate, day-count convention, payment cycle, maturity), and it deterministically produces the full schedule of state transitions and cash flows. Same inputs, same answer, for the issuer, the investor, the risk manager, and the regulator alike.
That made ACTUS excellent for what it was designed for: normalization, simulation, valuation, and risk analysis. But ACTUS stops at the model boundary. It tells you what should happen. It doesn't move money, transfer ownership, or enforce a covenant.
ACTUS solved standardization. Execution was still an open problem. And execution is precisely what a deterministic, replicated state machine - a blockchain VM - is for.
The AVM as the execution layer of ACTUS
D-ASA's pipeline is one line:
ACTUS Contract -> AVM Normalization -> ABI Upload -> AVM Execution
A debt instrument is defined through standard ACTUS contract attributes. The D-ASA SDK then normalizes the contract into AVM-native structures, preserving ACTUS semantics while respecting AVM constraints:
- ISO 8601 timestamps become UNIX seconds;
- floating-point quantities become fixed-point integers;
- the event schedule is generated off-chain and persisted on-chain in pages;
- the supported debt families are normalized into one common execution model.
These are the touching points to mount the financial standard into the execution environment, and they are explicit and documented: time format, numeric precision, and fixed-point arithmetic. Everything else is ACTUS as specified.
The normalized terms, initial contract state, and schedule are uploaded through the contract's ABI, and from that point the AVM ACTUS Kernel takes over: it validates that each event is legal for the configured contract type, applies due events, transitions the contract state deterministically, and emits AVM events as proof of every applied transition.
That last point deserves emphasis, because it is the sentence that makes reconciliation teams sit up:
The ACTUS schedule defines what should happen. AVM execution events prove what did happen, leveraging Algorand’s post-quantum protected history to ensure long-term integrity
When the contract definition, the lifecycle state, the ownership registry, and the payment evidence all live in one deterministic machine with instant finality, "reconciliation" stops being an industry and becomes a database read.
The whole value chain, encoded (not just a token)
Many tokenization projects mint a token and stop. In many earlier approaches, “tokens” were pointers to off-chain paper contracts (at most a prospectus URL in the token metadata) rather than on-chain execution of the contract. D-ASA takes a full RWA tokenization approach: if you own the contract (the token), you own the cashflows (not just a pointer to a paper with a promise of a traditional wire transfer). D-ASA encodes the operating model of a debt instrument. The framework is built from five modules: RBAC, ACTUS Kernel, Accounting, Payment Agent, and Transfer Agent; assembled into a single Algorand standard application, and its role-based access control reads like the org chart of a real issuance:
| Role | Responsibility on-chain |
|
Arranger |
Configures the instrument, uploads the schedule, executes issuance (IED), assigns roles |
| Account Manger | Opens holder accounts, the natural seat for KYC providers and onboarding banks (whitelisting) |
| Primary Dealer | Reserves units during primary distribution (which can be integrated with primary market applications like auctions, etc.) |
| Trustee | Controls the contract's default/performance flag (or any other trusted operation, if needed) |
| Authority | Can suspend the contract or individual accounts (regulatory intervention) |
| Observer | Applies rate-reset events based on observed external data feed (indexes, covenant breaches, etc.) |
| Op Daemon | Optional permissionless automation executor for payment workflows |
Investor accounts are equally realistic. Each holder is identified by a holding address (which owns the units, possibly a custodian or an order book) and a payment address (which receives the cash flows, always the lender's rail). Custody and entitlement are separated exactly the way they are in the real world.
Even settlement is bilingual: cash flows can settle on-chain (a stablecoin) or off-chain in ISO 4217 currency, in which case the state machine still approves payment conditions and notarizes the amounts and timestamps of what was settled off-chain. That means D-ASA doesn't demand a big-bang migration: a payment agent can keep its existing rails and still gain a shared, machine-verifiable golden record.
Issuance, KYC and whitelisting, onboarding, primary distribution, secondary transfers (within configured transfer windows), payments, servicing, and supervisory controls: one contract, one interface, one single source of truth.
Scaling cash flows: fund once, settle lazily
Here is where the design gets genuinely interesting for engineers.
The naive way to pay a coupon on a tokenized bond is to loop over every holder and push a transfer: N holders, N transactions, and a stalled loop if any single transfer fails. That doesn't scale, and worse, it doesn't match how payment operations actually work.
D-ASA does something smarter. The kernel maintains global cumulative interest and principal indices for the whole contract, regardless of the fractional ownership (if any). Each holder position, on the other hand, carries lightweight asynchronous trackers: checkpoints of the last applied indices, a settled-event cursor, and claimable balances.
The cash-flow lifecycle then splits into two independent operations:
- fund_due_cashflows(...) processes due ACTUS cash events contract-wide, once - a single operation regardless of whether the bond has ten holders or a hundred thousand;
- claim_due_cashflows(holding_address, payment_info) settles one holder position: it computes the delta between the global indices and the account's checkpoints, multiplies by the holder's units, moves the result into claimable interest and principal, and pays out.
If the on-chain payment is executable, the transfer happens immediately. If it isn't - say the account is suspended - the claimable balance simply remains reserved for a later attempt. Nothing blocks, nothing loops, no position is ever computed until someone actually touches it.
This is asynchronous settlement by construction, and it mirrors operational reality: the payment agent funds the coupon on the pay date; holders and custodians claim their entitlements at their convenience. Funding is O(1) in the number of holders, claims are independent and parallel, and there is no mutable on-chain "nominal unit value" to update across the book - transfers and claims are purely unit- and index-based. This is the settlement architecture you would design for a distributed system, applied to fixed income.
DvP as a protocol primitive
Delivery-versus-payment is the heart of securities settlement, and entire market infrastructures exist to approximate it. On Algorand, it isn't an approximation.
Algorand atomic transaction groups are a base-layer primitive: a group of transactions either all execute, or none do. A D-ASA DvP is simply a group containing a delivery leg (the Transfer Agent moves units) and a payment leg (any Algorand transaction, in any asset - not restricted to the denomination or settlement asset). No escrow contract, no hashed-timelock choreography, no settlement window.
The delivery leg and the payment leg succeed together or fail together. There is no principal settlement risk to either party during the exchange.
Combine that with Algorand's instant finality - no probabilistic settlement, no reorgs, no fails-to-deliver - and both primary placement and secondary OTC trades settle atomically, with terms negotiated freely between the parties. T+2 becomes T+one-block (2.5 seconds, instantly final).
It's Python. (And TypeScript.)
To a decision maker, the question after "what does it do" is "what does it cost to build on". This is where the AVM quietly wins.
D-ASA's smart contracts are written in Algorand Python - real, typed Python compiled to AVM bytecode - organized into the five modules above. The AVM is equally programmable in native TypeScript. There is no bespoke contract language to hire for; the two most widespread languages in fintech engineering are first-class citizens.
Defining a real instrument looks like this: the same fixed-coupon bond the project's CLI demo issues (€10,000 principal, 2.00% nominal rate, 90-day coupon cycle):
from d_asa import (
Cycle,
make_pam_fixed_coupon_bond_profile,
normalize_contract_attributes,
)
# 1. Define the instrument as an ACTUS contract (PAM fixed-coupon bond)
attributes = make_pam_fixed_coupon_bond_profile(
contract_id=1,
status_date=today,
initial_exchange_date=issuance_date,
maturity_date=maturity_date,
notional_principal=principal, # EUR 10,000.00
nominal_interest_rate=0.02, # 2.00%
interest_payment_cycle=Cycle.parse_cycle("90D"),
interest_payment_anchor=first_coupon_date,
)
# 2. Normalize ACTUS semantics into AVM-safe structures
normalized = normalize_contract_attributes(
attributes,
denomination_asset_id=eur.id,
denomination_asset_decimals=eur.decimals,
notional_unit_value=minimum_denomination,
)
# 3. Deploy, upload the schedule, and run the lifecycle on-chain
From there, the high-level DAsa API exposes role-oriented wrappers (arranger, account manager, dealer, trustee, authority, observer, holder) plus holder tools for valuation, actualized positions, transfers, claims, and building OTC DvP groups.
And because the contracts ship an ARC-56 application specification, typed clients are generated, in Python and TypeScript alike. This is the point the ACTUS pedigree makes powerful: ACTUS is a well-defined taxonomy, so one normalized interface can both issue and analyze any contract in the covered families. A wallet, custodian, or analytics vendor integrates once and supports every instrument that speaks the interface - the exact opposite of today's world, where every issuance platform is a bespoke integration project.
D-ASA currently covers the fixed-income class of the ACTUS taxonomy (PAM, ANN, NAM, LAM, LAX, and CLM), which spans bullet bonds, term deposits, mortgages, level-payment annuities and leasing, adjustable-rate mortgages, amortizing loans, teaser-rate loans, and callable loans. The same normalization-and-kernel pattern extends across the rest of the taxonomy.
The developer loop is equally short: AlgoKit, a local network, end-to-end lifecycle tests, and a one-command showcase:
git clone git@github.com:cusma/d-asa.git && cd d-asa && ./d-asa run
That command issues fixed-coupon and zero-coupon bonds on a local Algorand network and walks their full lifecycle (issuance, distribution, coupons, maturity), leaving every transaction explorable in a local block explorer. From zero to a running ACTUS instrument in minutes.
Built for instruments that outlive cryptographic eras (aka post-quantum)
A 30-year mortgage issued today matures in 2056. A transfer agent's records obligations, a custodian's audit trail, a trustee's evidence of default handling - these must remain verifiable on a horizon where today's elliptic-curve signatures are not guaranteed to survive quantum computing (as Google and Coinbase reports noted early this year).
This is where Algorand offers something traditional workflows can uniquely appreciate: State Proofs and transactions signed with Falcon, a lattice-based, quantum-resilient signature scheme. Algorand's chain history is post-quantum protected - and every financial lifecycle event, every coupon payment, every transfer lands in that history. The immutable log of the instrument is not just tamper-evident today; it is designed to still be provable decades from now, with post-quantum protections an active and expanding area of the protocol's development.
Moreover, D-ASA contract roles (e.g., arranger, bondholders, etc.) can be implemented with Algorand’s native post-quantum accounts (authorizing actions with Falcon signatures.
For banks, payment agents, custodians, and transfer agents whose regulatory retention periods are measured in decades, that is not a crypto-native curiosity. It is the difference between a blockchain audit trail you can cite in 2045 and one you can't (see Algorand post-quantum roadmap for further details).
What this changes for capital markets
Pulling it together, for each seat at the table:
- Issuers and arrangers get programmable issuance, standardized deployment, and enforceable lifecycle execution; with operational roles (and their limits) encoded in the contract itself.
- Token holders get tokenized positions with unambiguous entitlements, transparent payment history, and atomic settlement that removes principal settlement risk on the on-chain exchange.
- Payment and transfer agents get an execution and evidence layer that matches their actual workflows: fund globally, scale settlement, notarize off-chain legs (instead of fighting them).
- Risk managers get continuity between the model and the market: the same ACTUS terms that feed analytics engines are the terms the live contract executes. Deterministic cash flows - when, how much, to whom - with no model-versus-reality gap.
- The market gets what ACTUS always promised, extended to operations: less fragmentation between definition, execution, and reconciliation and a cost base low enough to make smaller issuances, and entirely new markets, economically viable.
From "model the contract" to "run the contract"
ACTUS took financial contracts from prose to algorithms. D-ASA shows that the AVM can take them from algorithms to running systems - with instant finality, native atomic DvP, scalable asynchronous settlement, institutional role separation, and a post-quantum-protected audit trail and authorizations, programmed in the languages your teams already write.
The standard no longer stops at simulation. Run it yourself:
- Code: github.com/cusma/d-asa — then ./d-asa run
- Documentation and specification: cusma.github.io/d-asa
- The ACTUS standard: actusfrf.org
Disclaimers
- D-ASA is a personal project developed by an Algorand Foundation employee.
- D-ASA has not been designed, developed, or reviewed by the Algorand Foundation.
- D-ASA is maintained at best effort by its creator.
The views expressed in this blog are the author's own and do not necessarily represent the views or positions of the Algorand Foundation.
The content provided in this blog is for informational purposes only. The information is provided by the Algorand Foundation and while we strive to keep the information up-to-date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the blog or the information, products, services, or related graphics contained in the blog for any purpose. The content of this blog is not intended to be legal, financial, or investment advice nor is it an endorsement, guarantee, or investment recommendation. You should not take any action before conducting your own research or consulting with a qualified professional. Any reliance you place on such information is therefore strictly at your own risk. All companies are independent entities solely responsible for their operations, marketing, and compliance with applicable laws and regulations. All third-party brands and trademarks are the property of their respective owners, and their mention does not imply affiliation or endorsement. In no event will the Algorand Foundation nor any affiliates be liable for any loss or damage including without limitation, indirect, or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this blog. Through this blog, you may be able to link to other websites which are not under the control of the Algorand Foundation; the inclusion of any links does not imply a recommendation nor endorse the views expressed therein. Any statements about future plans, integrations, or protocol upgrades are forward-looking and subject to change.