[Feature] bond_amount is immutable post-initialize in tholos v1

[collinsezedike]

Summary

bond_amount is validated and set once in initialize (contracts/tholos/src/lib.rs:266-282) and read by assert_outcome (lib.rs:586) for every new assertion. There is no function anywhere in contracts/tholos/src/lib.rs that changes it afterward. A deployment that needs to adjust its bond, for example in response to real usage data, a token's price movement, or spam/griefing patterns observed in production, has no on-chain path to do so; the only option is deploying an entirely new contract instance.

This is the same class of gap as the admin-rotation issues (#128/#129), scoped narrowly to just this one parameter.

Scope

• Add a set_bond_amount(new_bond_amount) function, admin-gated the same way update_resolvers and set_paused already are, validated against the same bounds initialize already enforces (bond_amount > 0, bond_amount <= MAX_BOND_AMOUNT).
• Decided: a bond change applies only to assertions created after the change. No new snapshot field is needed for this: Assertion.bond (lib.rs:106) already pins the bond amount at creation, and every payout path (dispute at lib.rs:668, finalize at lib.rs:712/735, resolve at lib.rs:801) already reads assertion.bond, never the live DataKey::BondAmount, so this guarantee already holds structurally. Update Assertion.bond's doc comment to state this pinning explicitly (it's currently true only as an implicit consequence of no payout path re-reading DataKey::BondAmount, not stated anywhere), and add a regression test proving a set_bond_amount call doesn't retroactively change an already-open assertion's payout.
• Emit an event on change, and add tests covering the update itself, auth-gating, and bound validation.

Proposed approach

A direct set_bond_amount, gated by admin.require_auth(), reusing initialize's existing bond_amount <= 0 || bond_amount > MAX_BOND_AMOUNT check, writing straight to DataKey::BondAmount. Pair it with the doc-comment update and regression test described above so the pinning guarantee is explicit and tested rather than an unstated accident of the current code.

[Iker2522]

I'd like to take this issue on!

I can implement the admin-gated set_bond_amount functionality in contracts/tholos/src/lib.rs.

I will gate the function via admin.require_auth() and enforce the same validation bounds as initialize (0 < bond_amount <= MAX_BOND_AMOUNT). To preserve resolution payout integrity and avoid retroactive shifts for active assertions, I will snapshot the bond amount on each Assertion at creation time (matching the v2 policy-pinned model).

Additionally, I'll emit a structured event on updates and add Soroban tests covering authorization failure, boundary checks, event emission, and assertion state immutability across bond changes. All cargo checks will pass cleanly. PR ready in 1 day.

[Iker2522]

I'd like to take this issue on!

I can implement the admin-gated set_bond_amount functionality in contracts/tholos/src/lib.rs.

I will gate the function via admin.require_auth() and enforce the same validation bounds as initialize (0 < bond_amount <= MAX_BOND_AMOUNT). To preserve resolution payout integrity and avoid retroactive shifts for active assertions, I will snapshot the bond amount on each Assertion at creation time (matching the v2 policy-pinned model).

Additionally, I'll emit a structured event on updates and add Soroban tests covering authorization failure, boundary checks, event emission, and assertion state immutability across bond changes. All cargo checks will pass cleanly. PR ready in 1 day.

[ZacLou]

I'd like to work on this issue. I have relevant experience with this tech stack and can deliver a clean, well-tested PR. I can submit within 1-2 days.

[JohnArayaE]

I would like to work on this issue because allowing the bond amount to be updated safely gives deployments a way to respond to changing usage, token prices, and spam or griefing conditions without requiring a new contract deployment. I can add an admin-gated set_bond_amount(new_bond_amount) using the existing initialization bounds, emit the appropriate change event, and add tests for successful updates, authorization, and invalid values. I’ll also explicitly document and account for whether bond changes affect only newly created assertions or existing in-flight assertions, so the behavior and payout implications are clear rather than assumed.

[devkryssie]

hi maintainer i'll like to work on this issue and submit pr within 24hours

[devkryssie]

hi maintainer i'll like to work on this issue and submit pr within 24hours

[grantfox-oss]

🦊 GrantFox — @JohnArayaE has been assigned to this issue!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #134)
2. Your PR will be reviewed by the drydocs maintainers

Good luck! Track your progress on GrantFox.

[collinsezedike]

@JohnArayaE Updated the issue body: the open design question about whether a bond change affects in-flight assertions is now decided, not left to your discretion. Short version: it already only affects future assertions, since Assertion.bond pins the value at creation and no payout path re-reads the live DataKey::BondAmount. The added scope is just making that explicit (doc comment) and testing it (regression test), no per-assertion snapshot field needed. See the updated Scope section for specifics.