Spent the week thinking about why Dusk lists tokenized equity and debt and funds as separate categories rather than one bucket called securities.
They are separate because their lifecycles barely overlap.
Equity carries voting. Dividends arrive irregularly and vary by class. The register has to support corporate actions that change the shape of ownership itself. Splits and rights issues and new share classes.
Debt is almost the opposite. No voting. Payments on a fixed schedule that everyone knows in advance. But it has a maturity date and interest accrual and early redemption terms and default handling. All of that has to execute correctly or the instrument is broken.
Funds are different again. Subscriptions and redemptions rather than trading. Net asset value calculated periodically by someone offchain. Holdings that change constantly underneath a unit that stays stable.
So the same settlement layer has to carry three quite different asset behaviours. And the older Zedger requirement list already anticipated this by tracking transactional and voting and dividend eligible balances as separate figures rather than one number.
That design choice makes sense only if you were planning for equity from the start.
My caveat is that supporting three asset types in a specification is not the same as three asset types actually trading. The hard part with each of them is the edge cases and those only surface with real volume.
which asset type do you think goes onchain properly first
@Dusk #dusk $DUSK
They are separate because their lifecycles barely overlap.
Equity carries voting. Dividends arrive irregularly and vary by class. The register has to support corporate actions that change the shape of ownership itself. Splits and rights issues and new share classes.
Debt is almost the opposite. No voting. Payments on a fixed schedule that everyone knows in advance. But it has a maturity date and interest accrual and early redemption terms and default handling. All of that has to execute correctly or the instrument is broken.
Funds are different again. Subscriptions and redemptions rather than trading. Net asset value calculated periodically by someone offchain. Holdings that change constantly underneath a unit that stays stable.
So the same settlement layer has to carry three quite different asset behaviours. And the older Zedger requirement list already anticipated this by tracking transactional and voting and dividend eligible balances as separate figures rather than one number.
That design choice makes sense only if you were planning for equity from the start.
My caveat is that supporting three asset types in a specification is not the same as three asset types actually trading. The hard part with each of them is the edge cases and those only surface with real volume.
which asset type do you think goes onchain properly first
@Dusk #dusk $DUSK