Labels: type: bug, type: security, difficulty: intermediate, area: reward-engine
Why this matters now
set_token and set_registry are admin-callable functions that redirect all future cross-contract calls to a new address. If the admin provides a wrong address (e.g., an uninitialised contract, a user wallet, or a typo), every subsequent approve_proof call will panic at the cross-contract call site with a cryptic SDK error — not a clean engine error. There is no on-chain event emitted, no validation, and no rollback if the new address turns out to be broken.
Problem / What
set_token and set_registry in verification.rs:
pub fn set_token(e: Env, caller: Address, new_token: Address) {
caller.require_auth();
require_admin(&e, &caller);
storage::write_token(&e, &new_token);
}No event. No validation that new_token != current_token. No validation that new_token is a contract address (though Soroban addresses are typed, a user account address is accepted). No two-step pattern.
Additionally, set_registry does not check that the engine is registered as a sponsor on the new registry — if it isn't, every subsequent complete_task call will fail with "registry: unauthorized".
Key Challenges
- Soroban does not provide an on-chain way to call a "probe" function before committing the change; the best approach is a try-call or an explicit version check call in the setter.
- A
TokenUpdatedEvent and RegistryUpdatedEvent must be added.
- The same-address guard (
new_token == current_token) is a simple no-op protection.
Acceptance Criteria
Relevant files / functions
| File |
Symbol |
contracts/reward-engine/src/verification.rs |
set_token, set_registry |
Out of scope
- Two-step pattern for
set_token/set_registry (covered by Issue 16 pattern; optional extension)
- Changes to
set_oracle
Labels:
type: bug,type: security,difficulty: intermediate,area: reward-engineWhy this matters now
set_tokenandset_registryare admin-callable functions that redirect all future cross-contract calls to a new address. If the admin provides a wrong address (e.g., an uninitialised contract, a user wallet, or a typo), every subsequentapprove_proofcall will panic at the cross-contract call site with a cryptic SDK error — not a clean engine error. There is no on-chain event emitted, no validation, and no rollback if the new address turns out to be broken.Problem / What
set_tokenandset_registryinverification.rs:No event. No validation that
new_token != current_token. No validation thatnew_tokenis a contract address (though Soroban addresses are typed, a user account address is accepted). No two-step pattern.Additionally,
set_registrydoes not check that the engine is registered as a sponsor on the new registry — if it isn't, every subsequentcomplete_taskcall will fail with"registry: unauthorized".Key Challenges
TokenUpdatedEventandRegistryUpdatedEventmust be added.new_token == current_token) is a simple no-op protection.Acceptance Criteria
set_tokenemitsTokenUpdatedEvent { admin, previous_token, new_token }and panics ifnew_token == current_token.set_registryemitsRegistryUpdatedEvent { admin, previous_registry, new_registry }and panics ifnew_registry == current_registry.set_registrythe caller must ensure the engine is re-added as a sponsor on the new registry.test_set_tokenandtest_set_registrytests pass or are updated.Relevant files / functions
contracts/reward-engine/src/verification.rsset_token,set_registryOut of scope
set_token/set_registry(covered by Issue 16 pattern; optional extension)set_oracle