Repository navigation
[Hard] Execute passed funding proposals through a policy-versioned treasury authorization path #80
Description
Goal
Safely connect governance approval to an actual treasury withdrawal so passed funding proposals can execute exactly once under the policy that authorized them.
Scope
- Define the cross-contract authorization payload and bind it to proposal ID, treasury ID, destination, asset, amount, policy version, and expiry.
- Require governance to be an authorized treasury actor and reject stale policy versions.
- Ensure the treasury transfer and execution-state change are atomic.
- Emit reconstructable events in both contracts.
Security requirements
- No off-chain approval may authorize a transfer.
- Prevent replay across proposals, contracts, assets, destinations, and policy versions.
- Verify the treasury has real token balance before execution.
Acceptance criteria
- A passed, unexpired, authorized proposal transfers the intended asset once.
- Failed transfer, insufficient funds, expired proposal, stale policy, or unauthorized governance leaves both contracts consistent.
- Integration tests use a real token client and cover replay/cross-contract misuse attempts.
- Events permit an indexer to reconstruct proposal-to-withdrawal linkage.
Out of scope
General arbitrary-contract execution or a frontend flow.
Activity
dannyy2000 commentedon Aug 23, 2026
Hi! I'd like to work on this issue. I have experience building Soroban smart contracts and working with governance, escrow, and security-sensitive authorization flows. I understand the core challenge is binding governance approval to a specific treasury execution without introducing replay or cross-contract authorization gaps.I'll implement a tightly scoped authorization payload covering the proposal, treasury, asset, destination, amount, policy version, and expiry, enforce authorization and stale-policy checks on-chain, and ensure the treasury transfer and execution state update remain atomic. I'll also add integration tests using real token transfers covering replay, cross-contract misuse, insufficient balance, expiry, and unauthorized execution, with reconstructable events for indexing.
Wilfred007 commentedon Aug 23, 2026
Hi! I’d like to work on this governance-to-treasury execution flow, focusing on making proposal execution secure, atomic, and exactly-once.
My approach would include:
Designing a domain-separated authorization payload bound to the proposal, treasury, destination, asset, amount, policy version, and expiry.
Enforcing on-chain governance authorization and rejecting stale policy versions or expired approvals.
Preventing replay across proposals, contracts, assets, destinations, and policy versions.
Making the treasury transfer and execution-state update atomic.
Verifying sufficient token balance before execution.
Emitting reconstructable events from both contracts for reliable auditing.
Adding tests covering replay attacks, stale policies, unauthorized execution, insufficient balances, and exactly-once execution.
I’ll prioritize security and explicit invariants so that no off-chain approval can independently authorize a treasury withdrawal.
grantfox-oss commentedon Aug 23, 2026
🦊 GrantFox — @Wilfred007 has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #80)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Aug 27, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!
@Wilfred007's PR #84 was approved and merged by @xqcxx.
🏆 @Wilfred007: You earned 40 FoxPoints for this contribution! Your current tier: Builder (1,108 total points). Track your full progress on GrantFox.
👏 Great work, @Wilfred007! Keep contributing to Stellar-Re-Code.