Two sender functions in Dusk smart contracts caught my attention: caller() and public_sender().
They sound like two ways to answer the same question, who initiated this action, but they can point to different actors. That distinction matters as Dusk pushes to bring financial markets onchain with EU-licensed institutions, where authorization has to survive more complex contract interactions without losing track of the original actor. caller() identifies the contract making the immediate call, while public_sender() can still point back to the Moonlight account that started the transaction.
What I don't know yet is whether Dusk contracts will consistently authorize the user who actually initiated an action, or whether adding intermediate contracts can quietly change which identity the authorization logic sees. The mechanics worth watching are straightforward: when contracts rely on caller(), when they rely on public_sender(), and what happens once batchers or forwarders sit in the middle.
A transaction executing successfully is not enough to answer that. The stronger test is whether the same authorization rules still point back to the intended actor even when the execution path changes.
I'd care less about how many intermediate contracts an action passes through than whether authorization still resolves to the actor who actually initiated it.
That matters because adding an intermediary can change who a contract sees without changing who actually authorized the action.
The question is whether Dusk can add more composable execution paths without making authorization depend on whichever contract happens to sit in the middle.
I am watching how caller() and public_sender() are used as those patterns develop.
@Dusk $DUSK #dusk
They sound like two ways to answer the same question, who initiated this action, but they can point to different actors. That distinction matters as Dusk pushes to bring financial markets onchain with EU-licensed institutions, where authorization has to survive more complex contract interactions without losing track of the original actor. caller() identifies the contract making the immediate call, while public_sender() can still point back to the Moonlight account that started the transaction.
What I don't know yet is whether Dusk contracts will consistently authorize the user who actually initiated an action, or whether adding intermediate contracts can quietly change which identity the authorization logic sees. The mechanics worth watching are straightforward: when contracts rely on caller(), when they rely on public_sender(), and what happens once batchers or forwarders sit in the middle.
A transaction executing successfully is not enough to answer that. The stronger test is whether the same authorization rules still point back to the intended actor even when the execution path changes.
I'd care less about how many intermediate contracts an action passes through than whether authorization still resolves to the actor who actually initiated it.
That matters because adding an intermediary can change who a contract sees without changing who actually authorized the action.
The question is whether Dusk can add more composable execution paths without making authorization depend on whichever contract happens to sit in the middle.
I am watching how caller() and public_sender() are used as those patterns develop.
@Dusk $DUSK #dusk
