You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bridge proposals have no proposer field, blocking relayer attribution #495
bft_consensus.rs::create_proposal builds and stores a cross-chain proposal but never records which relayer/caller submitted it:
/// # TODO/// - Add a proposer field so off-chain indexers can attribute proposals/// to specific relayers for analytics and accountability.pubfncreate_proposal(env:&Env,message:CrossChainMessage) -> Result<u64,BridgeError>{
...}
Without a stored proposer, the indexer (indexer/) and any off-chain analytics/reputation system have no on-chain way to attribute a proposal to the relayer that submitted it. This blocks per-relayer accountability (e.g., penalizing relayers who repeatedly submit invalid/expiring proposals) and per-relayer analytics on the observability dashboards already built for issue #321.
Implementation Plan
Add a proposer: Address field to the proposal struct, captured via env.current_contract_address()/caller identity at creation time in create_proposal, with require_auth() on the proposer.
Emit the proposer in the proposal-created event so the indexer can pick it up without an extra storage read.
Update indexer models/queries (if applicable) to surface proposer in proposal analytics.
Add a test confirming the stored proposal and emitted event both carry the correct proposer address.
Acceptance Criteria
Every created proposal records a proposer address
The proposer is authenticated (require_auth) at creation time
Hi maintainer, I’d love to work on this issue. I have experience with Rust and Soroban smart contracts, and I’m comfortable working with authorization, contract storage, events, and cross-chain systems. I can implement proposer attribution, update the relevant indexer logic, and add tests to verify the proposer is correctly stored, authenticated, and emitted in events.
Activity
Anuoluwapo25 commentedon Aug 18, 2026
Hi maintainer, I’d love to work on this issue. I have experience with Rust and Soroban smart contracts, and I’m comfortable working with authorization, contract storage, events, and cross-chain systems. I can implement proposer attribution, update the relevant indexer logic, and add tests to verify the proposer is correctly stored, authenticated, and emitted in events.
grantfox-oss commentedon Aug 20, 2026
🦊 GrantFox — @Anuoluwapo25 has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #495)Good luck! Track your progress on GrantFox.
fix(bridge): record proposer on bridge proposals for relayer attribution
grantfox-oss commentedon Sep 7, 2026
🎉 This issue has been marked as completed on GrantFox!
@Anuoluwapo25's PR #505 was approved and merged by @RUKAYAT-CODER.
🏆 @Anuoluwapo25: You earned 40 FoxPoints for this contribution! Your current tier: Builder (1,225 total points). Track your full progress on GrantFox.
👏 Great work, @Anuoluwapo25! Keep contributing to rinafcode.