Been sitting with Dusk's XSC standard, and the part that stuck: settlement and transfer eligibility are two separate layers, not one. #dusk @Dusk's Phoenix/Moonlight rails give a security token cryptographic finality in seconds. But an XSC transfer still needs the receiving wallet cleared by the issuer's access-control layer — no clearance, no transfer, regardless of finality.
This isn't just old design docs. Dusk's own 2019 STO framework describes whitelisting so issuers can keep ineligible parties out even after an offering closes. More telling: Dusk's current site states NPEX's full $300M+ managed asset base is tokenized on Dusk now, running on "access controls, privacy with selective disclosure, deterministic finality" as one stack — meaning this gating isn't hypothetical, it's live infrastructure under real assets.
What changed for me was realizing tokenized RWA on $DUSK SK doesn't mean permissionless liquidity. It means programmable permission. The chain kills settlement friction; it doesn't remove the gatekeeper, it just gives the gatekeeper faster tooling.
Next thing I want to check: whether an access-control decision on a live NPEX-issued asset — approving or blocking a wallet — is itself a queryable on-chain event, or something that only shows up as a transaction simply failing, with the reasoning held off-chain.
#dusk
@Dusk