#dusk $DUSK
What caught my attention was not the €300M figure attached to NPEX it was a smaller detail buried in Dusk's market infrastructure docs: before any asset can move a wallet has to be bound to a Verified participant. Not KYC'd once and forgotten. Bound per asset as an enforceable transfer condition.
I wanted to check what that actually means mechanically because compliant tokenization gets thrown around loosely.
Here's the sequence Dusk documents for something like NPEX's onboarding: an issuer defines eligibility rules for the asset. Investors' wallets get bound to verified credentials. From that point, the Transfer contract layer enforces who's even allowed to hold or move the token the restriction lives at the settlement layer not in a frontend checkbox. Settlement itself ties the asset leg and payment leg together for deterministic finality, so you don't get a state where shares moved but payment didn't.
Why this matters: NPEX is a Dutch MTF under AFM supervision. It can't just point at a public ERC-20 and call it a security. The eligibility check has to be enforceable on chain not just at the interface otherwise the Regulated part is theater.
The part I'd want to verify and haven't seen fully specified: what happens when eligibility changes an investor gets deregistered or a jurisdiction rule updates for tokens already held. Does the binding get revoked retroactively or does it only gate future transfers?
That's the actual test of whether this is a real regulated asset system or a issuance time compliance check.
NPEX moving €300M is one data point. Whether transfer control logic holds up under a live regulatory edge case is the one that decides if this generalizes to the rest of the sector.
Genuinely curious how Dusk handles the revocation case anyone dug into the Zedger/Hedger controlled Transfer spec closely Enough to know?
@Dusk_Foundation $DUSK #dusk
What caught my attention was not the €300M figure attached to NPEX it was a smaller detail buried in Dusk's market infrastructure docs: before any asset can move a wallet has to be bound to a Verified participant. Not KYC'd once and forgotten. Bound per asset as an enforceable transfer condition.
I wanted to check what that actually means mechanically because compliant tokenization gets thrown around loosely.
Here's the sequence Dusk documents for something like NPEX's onboarding: an issuer defines eligibility rules for the asset. Investors' wallets get bound to verified credentials. From that point, the Transfer contract layer enforces who's even allowed to hold or move the token the restriction lives at the settlement layer not in a frontend checkbox. Settlement itself ties the asset leg and payment leg together for deterministic finality, so you don't get a state where shares moved but payment didn't.
Why this matters: NPEX is a Dutch MTF under AFM supervision. It can't just point at a public ERC-20 and call it a security. The eligibility check has to be enforceable on chain not just at the interface otherwise the Regulated part is theater.
The part I'd want to verify and haven't seen fully specified: what happens when eligibility changes an investor gets deregistered or a jurisdiction rule updates for tokens already held. Does the binding get revoked retroactively or does it only gate future transfers?
That's the actual test of whether this is a real regulated asset system or a issuance time compliance check.
NPEX moving €300M is one data point. Whether transfer control logic holds up under a live regulatory edge case is the one that decides if this generalizes to the rest of the sector.
Genuinely curious how Dusk handles the revocation case anyone dug into the Zedger/Hedger controlled Transfer spec closely Enough to know?
@Dusk_Foundation $DUSK #dusk