Reclaim User Map Example

[ash-burnt]

Description

Contract Details

Please append all the required information below for the contract(s) being added to contracts.json.

Required fields and their descriptions:

• name: Contract name (required)
• description: Brief description of the contract's purpose
• code_id: Contract code ID on mainnet
• hash: Contract hash in UPPERCASE
• release:
  • url: URL to the release/commit (e.g., https://github.com/org/repo/releases/tag/v1.0.0)
  • version: Version tag or first 7 chars of commit hash
• author:
  • name: Organization name
  • url: Organization website URL
• governance: "Genesis" or proposal number
• deprecated: true if contract is deprecated (mixed inline with active contracts)

Example JSON structure:

{
  "name": "",
  "description": "",
  "code_id": "",
  "hash": "",
  "release": {
    "url": "",
    "version": ""
  },
  "author": {
    "name": "",
    "url": ""
  },
  "governance": "",
  "deprecated": false
}

Finding Code ID and Hash

To find the latest code ID and hash:

1. Run the verification tool which will show all code IDs on chain:

   node scripts/verify-code-ids.js

2. The new code ID will be shown in the mismatches as "exists on chain but not in contracts.json"
3. You can also query the code hash via the chain's RPC endpoint:

   xiond query wasm code-info <code-id> --node https://rpc.xion-mainnet-1.burnt.com

Documentation Updates

The README.md is automatically generated from contracts.json. After making changes:

1. Ensure you have the required dependencies:

   • Node.js: https://nodejs.org/
   • jq: brew install jq (macOS) or apt-get install jq (Ubuntu/Debian)

2. Run the convert script to validate and update the README:

   ./convert.sh

3. Commit both the contracts.json and generated README.md changes

⚠️ Important Notes:

• Do not edit README.md manually. All changes must be made through contracts.json
• Pull requests with manual README edits will be automatically rejected by CI
• If you forget to run ./convert.sh locally, the CI will fail with a "README out of sync" error

Validation

The convert.sh script automatically performs these validations:

• All required fields are present and properly formatted
• Hash is 64 characters and uppercase hex
• URLs are valid HTTPS links
• Code IDs are unique
• Contracts are ordered by code_id (both active and deprecated contracts follow the same ordering)
• README.md stays in sync with contracts.json

If any validation fails, the script will show specific error messages to help you fix the issues.

Checklist

• Added entry to contracts.json with all required fields
• Contract name is clear and descriptive
• Description explains the contract's purpose
• Code ID matches the mainnet deployed code
• Hash is in uppercase and matches the stored code
• Release URL points to the correct tag/commit
• Version matches the release tag or commit hash
• Author information is correct with valid URL
• Governance field correctly references proposal or "Genesis"
• Deprecated flag is set appropriately
• Entry is placed in code_id order (regardless of deprecated status)
• Ran ./convert.sh and fixed any validation errors
• Both contracts.json and generated README.md are included in the commit

Additional Notes

[crucible-burnt]

🔍 Crucible Security Review

Summary

Adds Reclaim User Map example contract for integrating with the Reclaim protocol. Stores user data based on verified Reclaim proofs.

Security Assessment

• Risk Level: Low (example contract for protocol integration)
• Instantiation validation: Address validation and non-empty claim key check ✓
• JSON parsing: Safe with error handling for missing extractedParameters and keys
• State management: Simple mapping of user address to verified value
• External calls: Delegates to verification contract after state update (proper ordering)
• No re-entrancy risk: State updated before external call

Immunefi Pattern Check

• ✅ Proper error handling
• ✅ No unvalidated external calls
• ✅ No state mutation vulnerabilities
• ✅ Claim key must match extracted parameter

False Report Risk

• Mark as example/educational contract to prevent incorrect security assumptions
• Add comments explaining Reclaim protocol flow

Code Quality

• Clean match statements
• Proper error types for each failure mode
• Good state separation

Recommendation

Approve - Clean integration example with proper error handling. Add documentation clarifying this is an example contract.

[crucible-burnt]

🔍 Crucible Security Review

Summary

New contract implementing a user→value map populated via Reclaim protocol proof verification. Users submit proofs that are verified by an external Reclaim contract, and extracted claim values are stored per-user.

Security Assessment

• Risk Level: Medium

Findings:

1. ⚠️ State stored before proof verification (src/contract.rs:51-55): USER_MAP.save() is called before the Reclaim verification sub-message executes. However, this is safe because CosmWasm executes atomically — if the Reclaim contract rejects the proof, the entire transaction reverts including the USER_MAP.save(). Not a vulnerability, but worth a comment for clarity.

2. JSON parsing uses HashMap<&str, Value> (src/contract.rs:44): The context field is parsed with borrowed string keys from the value input. This is fine for lifetime management since value lives for the duration of the function.

3. value.to_string() on serde_json::Value (src/contract.rs:50): This will include JSON quotes for string values (e.g., "\"hello\"" instead of "hello"). If consuming contracts/queries expect unquoted strings, this could cause issues. Consider using v.as_str().unwrap_or(&v.to_string()) for string values.

4. No access control on ExecuteMsg::Update: Any address can call Update and store a value for themselves. This is by design (self-sovereign claims), but verify this is intentional — there's no admin override or pause mechanism.

5. No value size limit: The verified_value string stored per user has no size bound. A malicious Reclaim proof with an extremely large extracted parameter could cause storage bloat. Consider adding a max value length check.

6. Pinned reclaim_xion dependency (Cargo.toml:21): Uses a specific git rev 5c67c33d — good for reproducibility, but should be periodically updated.

7. always_fail getrandom override (src/lib.rs:13-17): Standard CosmWasm pattern, correctly implemented.

Immunefi Pattern Check

• Trust boundary is the external Reclaim verification contract — if that contract has vulnerabilities, this contract's stored values could be based on invalid proofs
• No direct cryptographic operations — delegates to Reclaim contract
• No fee/gas manipulation vectors

False Report Risk

• The "state before verification" pattern could invite incorrect bug reports about TOCTOU or state manipulation. Consider adding a comment explaining CosmWasm's atomic execution guarantees.

Code Quality Notes

• Error types are minimal but appropriate
• No unit tests included — recommend adding tests for JSON parsing edge cases, empty context, missing keys
• Consider adding an admin/pause mechanism for emergency response

Status

Functional implementation with correct security model. Main recommendations: document the atomic execution assumption, fix to_string() quoting behavior, add value size limits, and include unit tests.