The get_secret function uses @owner in an equality check and in borrow_global````(@owner), but @owner is not defined anywhere. That makes the authorization check invalid and the code either won’t compile or — if modified incorrectly — will allow unauthorized reads of secrets. More importantly, the intended access control (“only the owner can read their secret”) is not implemented correctly
The bug is located in the get_secret view function:
In Move, @ is an operator, not a variable. The syntax @
is a shorthand for writing an address literal.owner is not a named address. The code uses @owner as if owner were a named address defined in the project's configuration. However, there is no indication that a named address called owner exists. Without this definition, the compiler has no idea what value @owner should resolve to.
Likelihood:
This is not a runtime issue that might occur under specific conditions; it is a guaranteed failure at the compilation stage.
Impact:
The module is completely unusable. It cannot be compiled or deployed.
Use owner: &signer so the runtime verifies the caller genuinely controls that account.
Return vector<u8> if you want binary-safe storage; otherwise return string::String.
exists<Vault>(addr) prevents panic when vault doesn't exist and provides a clear abort code.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.