Can a Dusk transaction succeed on-chain and still fail to deliver DUSK to the intended BSC address? Yes, because this bridge flow has two destinations hidden inside one user action.
In Dusk’s current mainnet-to-BSC workflow, the Web Wallet sends native DUSK to the official bridge account. The BSC recipient is not that transaction’s recipient field; it is carried in the memo. The bridge reads that EVM-formatted address and uses it to route the BEP20 payout.
That changes what “successful” means. A confirmed Dusk transaction proves that the source-side transfer reached the bridge account. It does not, by itself, prove that the destination payout was routed to the address the user intended. Dusk’s documentation warns that a missing or invalid memo cannot be processed automatically and may make the transfer unrecoverable.
So the memo is doing more than describing the transaction. In this workflow it is part of the delivery instruction.
I think that creates a useful boundary for wallets and bridge UX: once infrastructure consumes metadata to decide where value goes next, that metadata should be treated like transaction-critical input. The bridge account and the memo address deserve the same pre-send scrutiny.
A transaction hash can prove settlement. It cannot correct a routing instruction that was wrong before settlement.
@Dusk $DUSK #dusk $TRUMP $ZEC
In Dusk’s current mainnet-to-BSC workflow, the Web Wallet sends native DUSK to the official bridge account. The BSC recipient is not that transaction’s recipient field; it is carried in the memo. The bridge reads that EVM-formatted address and uses it to route the BEP20 payout.
That changes what “successful” means. A confirmed Dusk transaction proves that the source-side transfer reached the bridge account. It does not, by itself, prove that the destination payout was routed to the address the user intended. Dusk’s documentation warns that a missing or invalid memo cannot be processed automatically and may make the transfer unrecoverable.
So the memo is doing more than describing the transaction. In this workflow it is part of the delivery instruction.
I think that creates a useful boundary for wallets and bridge UX: once infrastructure consumes metadata to decide where value goes next, that metadata should be treated like transaction-critical input. The bridge account and the memo address deserve the same pre-send scrutiny.
A transaction hash can prove settlement. It cannot correct a routing instruction that was wrong before settlement.
@Dusk $DUSK #dusk $TRUMP $ZEC
