#dusk $DUSK @Dusk A Zedger transfer is not finished when you press “send” — the receiver still has a role to complete.
In Dusk’s Zedger design, a SEND operation does not immediately finalize the asset transfer for the receiver. The receiver must explicitly ACCEPT the transfer before it becomes part of their usable balance.
This creates an interesting design choice: ownership movement is not a single action, but a controlled lifecycle.
SEND creates the pending transfer. ACCEPT completes the receiver’s side. if acceptance never happens, the protocol has a defined expiry path instead of leaving the transfer state unresolved.
The important implication is that Zedger separates “initiating a transfer” from “finalizing a transfer.” This adds control, but it also means users and applications must handle transfer states carefully.
The mechanism is clear.
What interests me next is how often these pending states appear during real network activity?
@Dusk_Foundation $DUSK
In Dusk’s Zedger design, a SEND operation does not immediately finalize the asset transfer for the receiver. The receiver must explicitly ACCEPT the transfer before it becomes part of their usable balance.
This creates an interesting design choice: ownership movement is not a single action, but a controlled lifecycle.
SEND creates the pending transfer. ACCEPT completes the receiver’s side. if acceptance never happens, the protocol has a defined expiry path instead of leaving the transfer state unresolved.
The important implication is that Zedger separates “initiating a transfer” from “finalizing a transfer.” This adds control, but it also means users and applications must handle transfer states carefully.
The mechanism is clear.
What interests me next is how often these pending states appear during real network activity?
@Dusk_Foundation $DUSK