[CTR] Implement Merkle Tree Allowlist for Verified Technician Badge Minting

[Rampop01]

Issue #56

[CTR] Implement Merkle Tree Allowlist for Verified Technician Badge Minting

🟡 Priority: High
Difficulty: Hard
Estimated Effort: 3 days
Relevant Files: contracts/sbt/src/merkle.rs, contracts/sbt/src/lib.rs
Labels: crypto, nft, identity, priority:high

Requirements

1. Merkle Allowlist

   • Store a merkle_root: BytesN<32> in the SBT contract's instance storage, updatable only by the Admin.
   • Expose a mint_verified_badge(proof: Vec<BytesN<32>>, address: Address) function.
   • Implement on-chain Merkle proof verification: hash the address, traverse the proof, and confirm the computed root matches merkle_root.
   • Only mint the 'Verified Professional' Soulbound Badge if the proof is valid — revert with Error::InvalidProof otherwise.

2. Testing Requirements

   • Unit test: Generate a Merkle tree of 100 addresses off-chain, submit a valid proof for address #47, and assert the badge is minted.
   • Unit test: Submit a tampered proof and assert the function panics with Error::InvalidProof.

---

[Phantomcall]

I’d like to take this on. I have experience working with Rust and Soroban smart contracts, including authorization, token/SBT-style contract logic, and comprehensive contract testing. I’m also comfortable implementing cryptographic verification logic where correctness and deterministic behavior are critical.

I’ll implement the Merkle allowlist by adding merkle_root: BytesN<32> to instance storage with an admin-only update path, then implement mint_verified_badge to verify the caller’s address against the stored root before minting the Verified Professional Soulbound Badge. The proof verification will hash the address into the leaf, process each sibling in the supplied proof in the correct ordering, and compare the resulting hash against the configured Merkle root. Invalid proofs will fail explicitly with Error::InvalidProof.

I’ll pay particular attention to the hashing and node-ordering convention so the on-chain implementation matches the off-chain tree generation exactly, including handling of odd tree levels and deterministic leaf construction. I’ll also ensure unauthorized attempts to update the Merkle root cannot modify the allowlist.

For testing, I’ll generate a deterministic Merkle tree containing 100 addresses, generate the proof for address #47, and verify that a valid proof successfully mints the badge. I’ll add negative coverage for tampered proofs, incorrect addresses, modified Merkle roots, malformed proofs, and unauthorized root updates, confirming they fail with the expected errors.

I’ll follow the existing SBT contract storage, error, event, and authorization patterns rather than introducing a separate mechanism, and I’ll run the contract test suite and formatting/checks before submitting the PR.

[Peculiarr7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. I’ll prioritize this immediately and ensure a reliable solution is delivered as soon as possible. Thank you!