I expected a chain built for regulated markets to ship with a long list of native contracts. Compliance, identity, registry, the lot, all baked in at genesis.
Dusk ships two. Stake and Transfer.
Stake tracks provisioners, stakes, rewards and validator set management. Transfer moves DUSK and acts as the entry point for transaction execution and gas payment.
Thats the whole genesis set.
Everything regulated sits above it. Zedger on DuskVM, Hedger on DuskEVM, Citadel for identity, Dusk Trade as the product surface. None of it welded into the base.
The reasoning I'd give is that requirements move. Eligibility rules, disclosure obligations and reporting formats change with regulation, and anything at genesis changes only with a hard fork. Putting compliance logic in the base layer would mean a chain that needs a fork every time a directive is updated.
The counterpoint is real though. A thin base means the guarantees people actually care about live in contracts that can be upgraded, and upgradeable is a diferent security promise then immutable.
Should the parts most likely to change sit furthest from consensus, or does that just move the risk somewhere less examined?
Thin base, or thin guarantees?
#dusk @Dusk $DUSK