WHY A BLOCKCHAIN EVENT ISN'T THE SAME AS FINALITY
I used to think an exchange mainly needed to know when a blockchain transaction happened. But looking at Dusk made me question that. If a transaction can still change, I’m not sure an exchange should treat that event like final money.
That’s why RUES (Rusk Universal Event System) caught my attention. Dusk specifically lists RUES for infrastructure, indexers and exchanges. To me, the interesting part is what the exchange does after receiving the event.
Dusk’s transaction lifecycle separates included, executed, confirmed and finalized. Its docs say to monitor transaction executed, check for errors, confirm the block is finalized, and re-listen if a block reverts. I can see why this matters: crediting an exchange too early could turn a temporary state into a real balance.
I keep thinking about courier tracking here. If my parcel says “out for delivery”, I know it is moving, but I wouldn’t mark it delivered yet. Maybe I’m being too cautious, but I can see why an exchange would want that same gap between “moving” and “delivered”.
The idempotency detail made me stop again. Dusk tells deposit scanners to use the Dusk transaction ID as the idempotency key, not the memo, and to write the credit and block checkpoint atomically. So if the scanner crashes and scans the same range again, that transaction shouldn’t become a second deposit.
And now I’m wondering if I was looking at RUES too simply. If an exchange has to think about the event, finality, reverts and duplicate processing separately, how much of the real work is actually happening after the blockchain says something happened? @Dusk_Foundation #dusk $DUSK
I used to think an exchange mainly needed to know when a blockchain transaction happened. But looking at Dusk made me question that. If a transaction can still change, I’m not sure an exchange should treat that event like final money.
That’s why RUES (Rusk Universal Event System) caught my attention. Dusk specifically lists RUES for infrastructure, indexers and exchanges. To me, the interesting part is what the exchange does after receiving the event.
Dusk’s transaction lifecycle separates included, executed, confirmed and finalized. Its docs say to monitor transaction executed, check for errors, confirm the block is finalized, and re-listen if a block reverts. I can see why this matters: crediting an exchange too early could turn a temporary state into a real balance.
I keep thinking about courier tracking here. If my parcel says “out for delivery”, I know it is moving, but I wouldn’t mark it delivered yet. Maybe I’m being too cautious, but I can see why an exchange would want that same gap between “moving” and “delivered”.
The idempotency detail made me stop again. Dusk tells deposit scanners to use the Dusk transaction ID as the idempotency key, not the memo, and to write the credit and block checkpoint atomically. So if the scanner crashes and scans the same range again, that transaction shouldn’t become a second deposit.
And now I’m wondering if I was looking at RUES too simply. If an exchange has to think about the event, finality, reverts and duplicate processing separately, how much of the real work is actually happening after the blockchain says something happened? @Dusk_Foundation #dusk $DUSK