DeBazaar

Demo

About

DeBazaar DeBazaar is a decentralized marketplace that allows two strangers to safely trade any digital good using crypto. It replaces risky P2P deals in Telegram DMs with on-chain escrow, verifiable delivery checks, and decentralized arbitration, ensuring both sides are protected. 1. System Overview DeBazaar currently consists of three core components: 1.1. Frontend (Web App) - Buyers can browse listings and make payments securely. - Sellers can list any digital product — game assets, accounts, activation keys, NFT ownership, and more. - The UI guides users through creating an escrowed deal, avoiding unsafe off-chain trades. 1.2. Backend / Coordinator - Coordinates trade flow and tracks deal states. - Manages disputes and integrates with oracle verification. - Bridges the frontend UX with the smart contract trust layer. 1.3. Smart Contracts (Escrow + Arbitration) This is the trust layer of DeBazaar. - Escrow Contract: Locks buyer funds and releases them only when conditions are met. - Arbitration Contract: Enables dispute resolution via randomly selected arbiters. 2. Settlement Paths DeBazaar supports three types of settlement flows, depending on asset verifiability: 2.1. On-Chain Assets For crypto-native assets that exist entirely on-chain (NFTs, ERC-20 tokens, contract ownership, etc.): - Buyer locks funds in escrow. - Seller proves delivery on-chain. - Smart contract automatically releases funds. 2.2. API-Verifiable Assets For off-chain actions or assets verifiable via API: - Uses oracle functions (e.g., Chainlink Functions) to validate delivery. - Example: Buyer pays for a Twitter repost. - Buyer escrows funds. - Seller reposts. - Smart contract queries the Twitter API via oracle. - If verified, funds are released. 2.3. Human-Arbitrated Disputes For cases where delivery cannot be automatically verified, yet: - Either party can open a dispute. - The Arbitration contract uses verifiable randomness (e.g., Pyth VRF) to select a random jury from a pool of arbiters. - Arbiters are added to a private Telegram group with buyer and seller. - Both sides submit evidence. - Arbiters vote, and the final decision determines fund release or refund. 3. Summary DeBazaar replaces “trust a random middleman” with: ✅ On-chain escrow ✅ Verifiable delivery checks ✅ Decentralized human arbitration It’s designed to handle both crypto-native assets and the massive gray market of off-chain digital goods that people already trade today. 4. Test Transactions (Arbitrum Sepolia) Here are live examples of all three settlement paths: 4.1. On-Chain NFT - Listing: https://sepolia.arbiscan.io/tx/0x689e4619affc568f87c5e069d49c61a34c7d228507ad7952725a71a4759427b5 - Fill: https://sepolia.arbiscan.io/tx/0x9828b6e93df062fbb3be5e1a8a5375726b51b2b7113121281a2726c6f7e61f75 - Deliver & Release: https://sepolia.arbiscan.io/tx/0xec7a87315a9360bc6b937c165dfa783dd0d7754868d1c1cfb44873c7a8edf622 4.2. Off-Chain Retweet - Listing: https://sepolia.arbiscan.io/tx/0x556657b1b330ddd00c9a3fd5cf1a737586f5559f4de360a7b32ad7d765a00c40 - Fill: https://sepolia.arbiscan.io/tx/0xf0bf3354d67042ea08209edd3be3fd5ffc30d0551d27ff1ca29195f97cbd185d - Deliver & Release: https://sepolia.arbiscan.io/tx/0xf5ea9bf858e6ac6ea0d5038a2695a23e7011aeadb7db7a5b505928a930afce9f 4.3. Dispute Flow - Listing: https://sepolia.arbiscan.io/tx/0x2dc76c8d76af281e0029a12ac6b77c7e29db177ae7cb2bcb0bed44fe8e5791ab - Fill: https://sepolia.arbiscan.io/tx/0xc58ca64c6676ef17636af91481fedec798fa0ad5669e43e30ccac8a9adbd4723 - Deliver: https://sepolia.arbiscan.io/tx/0x6bbae4bd453506d1b8c9cc5f8fdd03337b04759450b5fee5aa55cb35346ad45c - Dispute: https://sepolia.arbiscan.io/tx/0xe66ad698257054a81e072a0e701f8a5d15b1ac338ae11d62a08bfb191ddd9c36 - Resolve: https://sepolia.arbiscan.io/tx/0x268ff86fd3183f7fba68d448dfa6f67660857148274e673d73632d7fe09942d8 5. Documentation Full project details — including roadmap, architecture overview, and market research — are available in our GitHub documentation: https://github.com/4rdii/debazaar-marketplace/tree/main/docs.

How it's made

Architecture Overview Built as a full-stack dApp with both on-chain and off-chain components. 1. Smart Contracts (Solidity) Tech Stack: - Solidity ^0.8.28 - Hardhat 3.0.7 - ethers.js v6 1.1. Contracts - 'DebazaarEscrow.sol' – Core marketplace with three escrow flows: 1. API Approval: via Chainlink Functions 2. On-chain Approval: state verification 3. Disputable: arbiter-mediated resolution - 'DebazaarArbiter.sol' – Dispute resolution with randomized arbiter selection using Pyth Entropy V2 - 'FunctionsConsumerUpgradable.sol' – Proxy consumer for "Chainlink Functions" 1.2. Notable Features - Randomized arbiter selection using Pyth Entropy V2 for fairness and efficiency - Web2 API integration through Chainlink Functions, allowing smart contracts to verify ownership of any offchain asset (e.g. in-game items, twitter reposts, etc.) - Cross-chain NFT marketplace support enabled via Chainlink Functions - On-chain proof mechanism using a static call approach, enabling verifiable off-chain actions — unlike existing on-chain marketplaces - EIP-712 permit-based arbitration, where permits must match arbiter order (see lines 109–114 in DebazaarArbiter.sol) 2. Backend (Python/Django) Tech Stack: - Django 4.2.7 - Django REST Framework (DRF) - Web3.py '6.11.3 - PostgreSQL 2.1. Components - REST API for listing management - Building unsigned transactions for frontend signing via MetaMask - ABI encoding for Chainlink Functions through 'transaction_builder.py' - 'addresses.py`' loads contract addresses from deployment artifacts - 'abis/' loader manages ABI data for all contracts 2.2. Notable Features - Frontend-signing pattern: backend builds, frontend signs and executes - JavaScript source flattening for Chainlink Functions - On-chain verification via multicall - PYUSD used as the single purchase token 3. Frontend (React) Tech Stack: - React 18.2 - ethers.js 5.7.2 3.1. Features - Browse and create listings - MetaMask integration with network switching - Multi-step transaction flows with status indicators - Direct UX for listings 3.2. Notable Features - Wallet-first architecture (platform context only for merchant identity) - Gas-optimized staging: approval → fill → delivery - Chainlink Functions secrets managed via GitHub Gist 4. Partner Technologies - Pyth Entropy V2: Unbiased arbiter selection - PYUSD: Stable main payment token - HardhatV3: Smart contract development and deployment 5. Benefits - Pyth provides verifiable randomness without a VRF delay - PYUSD offers price stability and accessibility - HardhatV3 provides a secure and reliable development environment 6. Hacks & Workarounds - Arbitrum Sepolia contract verification issue: Encountered a bug and lack of documentation regarding chainDescriptor setup for contract verification. Resolved manually through Hardhat’s extended configuration. - Entropy integration: Integrated Pyth Entropy V2 for random arbiter selection — the flow was straightforward, reliable, and cost-efficient, providing verifiable randomness without the complexity of VRF callbacks. - Permit ordering for arbitration: Implemented strict EIP-712 permit ordering in DebazaarArbiter.sol, ensuring permits align with the randomized arbiter list to maintain fairness during disputes. - Proxy upgrades for Chainlink Functions: Used ERC1967 upgradeable proxy pattern to allow seamless updates of the Chainlink Functions consumer without redeploying dependent contracts. - Frontend-only signing: Enforced a frontend-only signing model—no private keys on the server—by building unsigned transactions on the backend and requiring MetaMask execution on the client. - API secrets handling: Managed Chainlink Functions’ API secrets through encrypted GitHub Gists, allowing secure and flexible off-chain verifications without exposing keys. - Static call verification pattern: Used a static call approach for on-chain verification, letting contracts safely validate off-chain claims without triggering state changes or high gas costs. 7. Deployment Smart Contracts: Hardhat Ignition Full Stack: Docker Compose orchestrating Django backend, PostgreSQL database, and React frontend, with Caddy as the web server