#dusk $DUSK @Dusk
What keeps bothering me about this whole Dusk situation isn’t the Zedger freeze itself.
That part actually works—position gets locked, DuskVM commits it, DuskDS finalizes, Rusk signs off. Clean.
It’s what happens after that bugs me.
So the regulated asset is frozen. Issuer ops sends the freeze record to legal. Legal wants confirmation the holder can’t move that specific position. Fair enough. Auditor then asks for the Phoenix audit view tied to that wallet—standard request on the surface.
But here’s the catch: that same wallet still holds other shielded notes. Completely unrelated. Different Phoenix notes, different spends, zero connection to the frozen Zedger position.
And that’s where my brain stalls every time.
What are we actually trying to prove here?
That the Zedger freeze worked? Or that we now get to peek into the rest of the wallet?
Because on Dusk, those are two separate jobs. Zedger handles the regulated lock. Phoenix keeps unrelated notes... well, unrelated. A viewing key that proves one freeze shouldn’t automatically double as a backstage pass to someone’s entire transaction history.
But that’s not how it’s playing out in practice.
The ugly reality is: it’s easier to just attach the broader Phoenix audit view to the freeze file than to generate a tighter, narrower disclosure. So that’s what happens. Then the next review comes around, and they ask for the same packet again. And before you know it, a simple freeze request now comes with a side order of unrelated note history—and somehow that becomes the new normal for issuer evidence.
I keep circling back to the same question: one frozen position, one finalized state—how much of someone’s shielded Phoenix activity does that actually entitle anyone to see?
The Zedger position itself? Sure, open that up.
But the other shielded notes and their spends? That’s still outside the scope of the freeze case. Always was.
@Dusk $DUSK
What keeps bothering me about this whole Dusk situation isn’t the Zedger freeze itself.
That part actually works—position gets locked, DuskVM commits it, DuskDS finalizes, Rusk signs off. Clean.
It’s what happens after that bugs me.
So the regulated asset is frozen. Issuer ops sends the freeze record to legal. Legal wants confirmation the holder can’t move that specific position. Fair enough. Auditor then asks for the Phoenix audit view tied to that wallet—standard request on the surface.
But here’s the catch: that same wallet still holds other shielded notes. Completely unrelated. Different Phoenix notes, different spends, zero connection to the frozen Zedger position.
And that’s where my brain stalls every time.
What are we actually trying to prove here?
That the Zedger freeze worked? Or that we now get to peek into the rest of the wallet?
Because on Dusk, those are two separate jobs. Zedger handles the regulated lock. Phoenix keeps unrelated notes... well, unrelated. A viewing key that proves one freeze shouldn’t automatically double as a backstage pass to someone’s entire transaction history.
But that’s not how it’s playing out in practice.
The ugly reality is: it’s easier to just attach the broader Phoenix audit view to the freeze file than to generate a tighter, narrower disclosure. So that’s what happens. Then the next review comes around, and they ask for the same packet again. And before you know it, a simple freeze request now comes with a side order of unrelated note history—and somehow that becomes the new normal for issuer evidence.
I keep circling back to the same question: one frozen position, one finalized state—how much of someone’s shielded Phoenix activity does that actually entitle anyone to see?
The Zedger position itself? Sure, open that up.
But the other shielded notes and their spends? That’s still outside the scope of the freeze case. Always was.
@Dusk $DUSK
