feat: M008 CosmWasm attestation-bonding contract with unit tests

[brawlaphant]

Summary

• Implements the M008 Data Attestation Bonding mechanism as a CosmWasm smart contract under contracts/attestation-bonding/
• Full attestation lifecycle: Bonded (with 48h activation delay) -> Active -> Released, with challenge/dispute/slash flows
• 42 unit tests covering all 20 SPEC acceptance test scenarios plus edge cases (bond conservation, arbiter neutrality, resolution finality, etc.)

Contract structure

File	Purpose
Cargo.toml	cosmwasm-std 2.2, cw-storage-plus 2.0, cw2, thiserror 2, schemars, serde
src/lib.rs	Module exports
src/error.rs	ContractError enum (13 error variants)
src/state.rs	Storage items, Config, Attestation, Challenge structs, status enums
src/msg.rs	InstantiateMsg, ExecuteMsg (7 variants), QueryMsg (8 variants), response types
src/contract.rs	Full implementation with instantiate/execute/query entry points + 42 unit tests

Key features per SPEC

• Attestation types: ProjectBoundary (500 REGEN min), BaselineMeasurement (1000), CreditIssuanceClaim (2000), MethodologyValidation (5000) with configurable lock/challenge periods
• 48h activation delay: Bonded -> Active transition requires delay, challengeable during delay
• Challenge deposit: 10% of bond amount (configurable via basis points)
• Resolution flows: AttesterWins (bond + deposit - fee returned) or ChallengerWins (50/50 slash to challenger + community pool)
• Arbiter fee: 5% of bond (configurable)
• Security invariants: Bond conservation, single active challenge, arbiter neutrality, resolution finality, lock period enforcement

Dependencies

• cosmwasm-std 2.2 (resolved to 2.3.2)
• cw-storage-plus 2.0
• cw2 2.0
• thiserror 2
• schemars 0.8, serde 1

Test plan

• cargo test — 42 tests pass (0 failed)
• Review alignment with SPEC.md acceptance tests 1-20
• Review integration points with M010 (reputation) and M009 (service escrow)
• Verify Cargo.toml dependency versions match repo conventions

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces the attestation-bonding CosmWasm contract, which implements a system for bonded ecological attestations and challenge-based dispute resolution. The contract manages the lifecycle of attestations, including bonding, activation delays, and arbiter-mediated slashing. Feedback identifies several critical security and scalability issues: the arbiter neutrality check needs to include beneficiaries to prevent conflicts of interest; queries for attestations and challenges require secondary indices to avoid gas-limit failures from full table scans; and additional input validation is necessary to prevent trapping extraneous funds, cap fee ratios, and ensure the challenge window does not exceed the bond lock period.

[gemini-code-assist]

The arbiter neutrality check is incomplete. According to the SPEC (Section 9, Security Invariants), arbiters cannot be the attester, challenger, or beneficiary. The current implementation only checks against the attester and challenger. This could allow a beneficiary to resolve a challenge in their own favor.

Suggested change

	if info.sender == attestation.attester || info.sender == challenge.challenger {
	return Err(ContractError::ArbiterConflict {});
	}
	if info.sender == attestation.attester || info.sender == challenge.challenger || attestation.beneficiary.as_ref() == Some(&info.sender) {
	return Err(ContractError::ArbiterConflict {});
	}

[gemini-code-assist]

This query performs a full table scan of all attestations to filter by attester. As the number of attestations grows, this query will become increasingly expensive and will eventually exceed the gas limit, causing it to fail. To support efficient pagination and filtering, a secondary index (e.g., a Map with (Addr, u64) as key) should be implemented in state.rs.

[gemini-code-assist]

Similar to the attester query, this performs a full scan of all challenges in the contract. This is inefficient and not scalable. An index should be used to map attestation IDs to their associated challenges.

[gemini-code-assist]

The contract does not validate that only the required bond denom is sent. If a user sends multiple coins in info.funds, any coins not matching config.bond_denom will be trapped in the contract with no mechanism for recovery. It is recommended to enforce that info.funds.len() == 1 and that the denom matches.

[gemini-code-assist]

Similar to attestation creation, the challenge mechanism does not validate that only the required deposit denom is sent. Any additional coins sent in info.funds will be trapped in the contract. Consider enforcing that only the expected denom and amount are provided.

[gemini-code-assist]

There is no validation on the updated ratios. If arbiter_fee_ratio is set to a value exceeding 10,000 (100%) or even 5,000 (50%), it could cause overflows or logic errors during challenge resolution (e.g., negative payouts for the challenger). Ratios should be capped at BASIS_POINTS_DIVISOR.

[gemini-code-assist]

The contract should validate that the challenge_window_days is less than or equal to the lock_period_days. If the challenge window exceeds the lock period, an attester could release their bond before the window for challenging has closed, effectively bypassing the economic security of the bond.