Calling init during deployment does not mean it loses its permissions forever. The DuskVM Reference clearly states that init remains an exported entry point after deployment. This detail shifts one-time initialization from a platform guarantee back to the contract’s own access control. If the code does not keep a state lock, deployment time is only an experience, not a permanent seal.
I split responsibility into two columns. The platform is responsible for creating the initial state and calling pub fn init with parameters during deployment. @Dusk The contract itself is responsible for recording whether it has already been initialized, rejecting repeated execution on later calls, and checking whether the caller has permission. The first column ensures the function is called; the second column ensures who can call again and how many times. The two columns cannot sign for each other.
The risk is not the name init, but what it may write. Administrator addresses, asset mappings, fee parameters, or external contract addresses: as long as second overwrite is allowed, the trust conditions formed by the first deployment will be reset. You cannot infer a vulnerability from the function name alone; the facts speak for themselves. Only when the specific code lacks a state flag or caller verification does repeated initialization become a real attack surface.
When looking at a contract’s initial configuration, $DUSK I would check three pieces of evidence. Is there an initialized flag in persistent state, does the second call explicitly fail, and is the caller verified before modifying critical fields? A deployment transaction can only answer that it executed at the time; it cannot answer who can execute later. If an audit only screenshots the first successful receipt, half of the permission issue is still left unresolved.
This two-column table also gives ordinary users a practical way to judge. If a project says the parameters were locked at deployment, you can keep asking whether the locking was done by the virtual machine or by the contract code. The former would not match the documentation; the latter should leave evidence in the source code and in repeated-call tests. init is the deployment entry point, and also a public entry point after deployment. Real one-time behavior does not rely on chronological order, but on state rejection and caller authorization. #dusk
I split responsibility into two columns. The platform is responsible for creating the initial state and calling pub fn init with parameters during deployment. @Dusk The contract itself is responsible for recording whether it has already been initialized, rejecting repeated execution on later calls, and checking whether the caller has permission. The first column ensures the function is called; the second column ensures who can call again and how many times. The two columns cannot sign for each other.
The risk is not the name init, but what it may write. Administrator addresses, asset mappings, fee parameters, or external contract addresses: as long as second overwrite is allowed, the trust conditions formed by the first deployment will be reset. You cannot infer a vulnerability from the function name alone; the facts speak for themselves. Only when the specific code lacks a state flag or caller verification does repeated initialization become a real attack surface.
When looking at a contract’s initial configuration, $DUSK I would check three pieces of evidence. Is there an initialized flag in persistent state, does the second call explicitly fail, and is the caller verified before modifying critical fields? A deployment transaction can only answer that it executed at the time; it cannot answer who can execute later. If an audit only screenshots the first successful receipt, half of the permission issue is still left unresolved.
This two-column table also gives ordinary users a practical way to judge. If a project says the parameters were locked at deployment, you can keep asking whether the locking was done by the virtual machine or by the contract code. The former would not match the documentation; the latter should leave evidence in the source code and in repeated-call tests. init is the deployment entry point, and also a public entry point after deployment. Real one-time behavior does not rely on chronological order, but on state rejection and caller authorization. #dusk