Feature: Participant blacklist and whitelist

[Samaro1]

This introduces participant blacklist and whitelist enforcement to the bounty_escrow contract, adding compliance and abuse-prevention controls while preserving existing default behavior. Admins can block sanctioned or malicious addresses, optionally restrict participation to a verified set, and audit every change through emitted events.

The core logic is implemented in
contracts/bounty_escrow/contracts/escrow/src/blacklist.rs and integrated into the main contract.

Key Features
Compliance Controls
Blacklist addresses to prevent them from locking or receiving funds
Optional whitelist-only mode to allow only verified participants
Unified validation via is_participant_allowed() used by core flows

Admin APIs
set_blacklist(env, address, blocked, reason)
set_whitelist(env, address, whitelisted)
set_whitelist_mode(env, enabled)

All modification functions require admin authorization.

Contract Enforcement
lock_funds() rejects blacklisted or non-whitelisted (in whitelist mode) depositors
release_funds() prevents transfers to blocked recipients
New error: ParticipantNotAllowed

Storage and Performance
Persistent maps for blacklist and whitelist data
Optional reason stored for blacklisted entries

Lookup for all checks
Events and Audit Trail
AddressBlacklisted / AddressUnblacklisted
AddressWhitelisted / AddressUnwhitelisted
WhitelistModeToggled
Every compliance action emits an event for traceability.

Backward Compatibility
Feature is opt-in; whitelist mode is disabled by default
Existing flows continue to work unchanged unless an address is explicitly blocked or whitelist mode is enabled
No breaking changes to existing contract state or API

Feature Tests
Dedicated blacklist/whitelist test suite: 2/2 passing
Blacklisted address cannot call lock_funds
Whitelist-only mode blocks non-whitelisted addresses

Core Contract Tests
Core initialization and fund flow tests compile and run successfully alongside the new checks
Integration Points Verified
Early participant validation added to lock_funds
Recipient validation added to release_funds
Both paths return ParticipantNotAllowed on violation

Files Added
contracts/bounty_escrow/contracts/escrow/src/blacklist.rs
contracts/bounty_escrow/contracts/escrow/src/test_blacklist.rs

Files Modified
contracts/bounty_escrow/contracts/escrow/src/lib.rs
Integrated blacklist module
Added participant validation in lock_funds and release_funds
Exposed admin management functions
Added ParticipantNotAllowed error

Closes #307

[vercel]

@Samaro1 is attempting to deploy a commit to the Jagadeesh B's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Jagadeeshftw]

LGTM!