The more I looked at Dusk’s contract-address logic, the more one small detail stood out.

Instead of thinking only in terms of a deployer’s key + nonce, Dusk’s execution state also tracks the current block height and how many contracts have already been created in that block.

That creates an interesting consequence.

If two contracts are deployed in the same block, their resulting addresses can depend on their position in that block’s execution sequence.

So even if both transactions were broadcast at almost exactly the same time, the resulting address may differ based on which deployment gets processed first.

That’s a subtle shift from the address-prediction assumptions many EVM developers are used to.

It doesn’t automatically make the design problematic. But it does create an important tooling question:

If you’re building a factory, deployment script, indexer, or anything that needs to know a contract address before deployment, how are you handling this dependency?

I hadn’t really questioned that assumption until I looked closely at Dusk’s execution model.

Curious to hear from developers building on @Dusk_Foundation

Have you ever had block ordering affect a pre-computed contract address?

#dusk $DUSK @Dusk