#dusk $DUSK @Dusk
The Zedger contract section has an operation most descriptions of Dusk's privacy model skip entirely — force transfers. It shows up in the whitepaper alongside minting and burning as a core part of what a Zedger contract supports, and it's worth understanding what it is.
Force transfer basics: the issuer of a Zedger security can initiate a transfer of that security from one holder's account to another, without requiring a signature from the current holder.
Worth thinking through what that actually means.
A normal Zedger transfer is holder-initiated. You construct the transaction, prove your eligibility, sign it. The holder is the actor. A force transfer inverts that. The issuer is the actor. The holder's account loses the position, and another account receives it, because the issuer submitted a transaction with that effect.
This sounds alarming at first, so it's worth saying: this isn't an oversight or a backdoor. It's a deliberate compliance feature. In traditional finance, regulators can compel asset transfers under a range of circumstances — and redirecting assets, AML enforcement actions, regulatory intervention, corrections of erroneous transfers. A security to because regulated markets sometimes require issuers to act on legal obligation rather than holder consent.
Not saying this is uncontroversial. In a self-custody model, the premise that nobody can move your assets without your signature is foundational. Force transfers deliberately carve out an exception to that for issuers, and how broadly or narrowly that power is scoped matters enormously.
Not saying it's wrong either. The alternative is a security token that's legally useless in any jurisdiction where forced transfers can be ordered.
What I haven't worked out is whether Zedger force transfers require any on-chain authorization proof — a signed regulatory order, a multisig approval — or whether the issuer key alone is sufficient to initiate one. @Dusk
$SPK $TAC
The Zedger contract section has an operation most descriptions of Dusk's privacy model skip entirely — force transfers. It shows up in the whitepaper alongside minting and burning as a core part of what a Zedger contract supports, and it's worth understanding what it is.
Force transfer basics: the issuer of a Zedger security can initiate a transfer of that security from one holder's account to another, without requiring a signature from the current holder.
Worth thinking through what that actually means.
A normal Zedger transfer is holder-initiated. You construct the transaction, prove your eligibility, sign it. The holder is the actor. A force transfer inverts that. The issuer is the actor. The holder's account loses the position, and another account receives it, because the issuer submitted a transaction with that effect.
This sounds alarming at first, so it's worth saying: this isn't an oversight or a backdoor. It's a deliberate compliance feature. In traditional finance, regulators can compel asset transfers under a range of circumstances — and redirecting assets, AML enforcement actions, regulatory intervention, corrections of erroneous transfers. A security to because regulated markets sometimes require issuers to act on legal obligation rather than holder consent.
Not saying this is uncontroversial. In a self-custody model, the premise that nobody can move your assets without your signature is foundational. Force transfers deliberately carve out an exception to that for issuers, and how broadly or narrowly that power is scoped matters enormously.
Not saying it's wrong either. The alternative is a security token that's legally useless in any jurisdiction where forced transfers can be ordered.
What I haven't worked out is whether Zedger force transfers require any on-chain authorization proof — a signed regulatory order, a multisig approval — or whether the issuer key alone is sufficient to initiate one. @Dusk
$SPK $TAC
