#dusk $DUSK @Dusk
What caught my attention while going through Dusk's docs: only two contracts exist At genesis the stake contract and the transfer contract. Everything else including DuskVM and DuskEVM sits on top of them.

That's a strange amount of concentration for a chain built to settle regulated assets. So I wanted to check what these two actually do and whether they can be changed later.

The stake contract tracks provisioners who is staked how much when rewards mature when slashing applies. The transfer contract handles both public (Moonlight) and shielded (Phoenix) balances and it's the only place contract to contract fund movement actually happens. Every execution environment routes through it for settlement and data availability per current docs.

Why that matters: if you are building on DuskEVM or issuing assets through Dusk Trade, you are not just trusting your own contract logic. You are trusting that these two genesis contracts behave correctly indefinitely since they are the settlement substrate underneath everything else.

Here is what I couldn't pin down. Docs describe these contracts being refactored over time the staking contract was rebuilt to fix a storage issue and later engineering updates changed its Event structure. So they clearly aren't frozen in the immutable at genesis sense.

What's unclear to me is the actual upgrade path: is it discretionary (protocol team ships a network upgrade) or is there a formal on chain governance step that provisioners vote on before genesis contract logic changes? The docs I found describe what the contracts do, not how modifications to them get authorized.

For a chain positioning itself for institutional settlement that distinction team authorized upgrade vs. provisioner ratified upgrade seems like it should be documented explicitly somewhere.

Has anyone seen where @Dusk specifies the actual Authorization process for genesis contract changes?

$DUSK #dusk