DareX

DareX: A Decentralized Social Challenge Platform DareX is a cutting-edge decentralized application (dApp) that transforms real-world challenges into a gamified, crypto-powered social experience. At its core, DareX is a platform where users can create, accept, and complete real-life "dares" for cryptocurrency rewards. The entire process, from a dare's creation to its final payout, is managed by smart contracts on the blockchain, ensuring transparency, fairness, and security.

The project is designed as a mini-app to run natively within the World App ecosystem, leveraging its secure and user-friendly environment.

Key Components and Technologies The DareX platform is a sophisticated blend of modern web technologies and core Web3 principles.

1. User Authentication: World App Wallet & SIWE Instead of traditional logins or requiring users to connect external wallets like MetaMask, DareX uses World App's native Wallet Authentication. This is the primary and only method for users to sign in.

How it Works: The application follows the Sign-In with Ethereum (SIWE) standard. When a user wants to log in, the app's backend generates a unique, secure message called a "nonce." The World App then prompts the user to sign this message with their wallet's private key. This signature, which proves ownership of the wallet without revealing any secrets, is sent back to the application's backend for verification. This process provides a highly secure, passwordless login experience.

1. Core Logic: Modular Smart Contracts The backbone of DareX is a set of modular smart contracts written in Solidity.

DareXModular.sol: This is the main contract that acts as the central hub. It handles the creation of new dares, linking participants to their submissions, and initiating the final reward distribution.

RewardDistribution.sol: When a user creates a dare, the crypto reward (e.g., PYUSD, ETH) is locked in this dedicated contract. This contract acts as a neutral escrow, automatically sending the reward to the winner upon successful completion or returning it to the creator if the dare is not completed successfully. This eliminates the need for any central party to manage funds.

Voting.sol: For every dare created, a new, unique Voting contract is deployed. This contract is responsible for managing the community-based voting process for that specific dare, ensuring that each challenge is judged independently.

1. Proof of Completion: Decentralized Storage with Filecoin A critical part of any dare is proving it was completed. DareX solves this in a decentralized way.

Filecoin & Lighthouse: When a participant completes a dare, they upload evidence, such as images or videos. These files are not stored on a traditional server, which could be a single point of failure. Instead, they are uploaded to the Filecoin network using the Lighthouse SDK. Lighthouse is a service that makes it easy to permanently store data on Filecoin and the InterPlanetary File System (IPFS).

Content Identifier (CID): Upon a successful upload, Lighthouse returns a unique Content Identifier (CID). This CID is a permanent, hash-based address for the proof files.

On-Chain Link: This CID is then stored on the blockchain as part of the dare's submission record in the DareXModular contract. This creates an unbreakable and publicly verifiable link between the on-chain dare and its off-chain proof, which can be viewed by anyone, anytime.

The User Journey The entire user experience is designed to be seamless and engaging.

Sign-In: A user opens DareX inside their World App and signs in with a single tap using their wallet.

Create a Dare: A user can create a new challenge, writing a title and description, and setting a crypto reward. The reward amount is then transferred from their wallet to the RewardDistribution contract.

Accept a Dare: Other users can browse the "Dare Marketplace" and accept challenges.

Submit Proof: After completing the dare, the participant uses the app to upload their video or photo proof. The files are sent to Filecoin, and the resulting CID is submitted to the smart contract.

Community Voting: Once a proof is submitted, the community is notified and can vote on its validity. This decentralized governance ensures fair play.

Reward Payout: After the dare's deadline, the completeDare function is triggered. The Voting contract reports the result. If the proof is deemed valid, the RewardDistribution contract automatically sends the crypto reward to the participant's wallet.

By integrating these technologies, DareX creates a trustless ecosystem for social challenges, where the rules are enforced by code, and the community is empowered to govern the platform.

How DareX is Made: A Technical Deep Dive DareX was conceived as a decentralized, mobile-first social platform. The architecture is a hybrid model, leveraging the strengths of a traditional web backend for certain tasks while relying on smart contracts for all core, trust-sensitive operations.

The Tech Stack Here's a look at the primary technologies used to build DareX and how they fit together.

Frontend: A Modern, Mobile-First Experience Framework: Next.js with the App Router. This was chosen for its robust support for both server-side rendering and client-side interactivity, which is crucial for a dynamic dApp.

UI Components: Shadcn/UI and Tailwind CSS. This combination provides a beautiful, accessible, and highly customizable component library that allows for rapid development of a polished user interface.

Web3 Integration:

Worldcoin MiniKit: This is the cornerstone of the user experience. Instead of forcing users to manage external wallets, we use MiniKit to integrate directly with the user's World App. This provides a seamless, one-tap sign-in process and access to the user's wallet for on-chain transactions.

Viem: A lightweight and powerful TypeScript interface for Ethereum. We use Viem to format transactions, interact with our smart contracts, and parse data returned from the blockchain.

Backend: Lean and Focused Framework: Node.js with Express.js. The backend has a very specific and limited role. It does not control user funds or manage core application logic.

Database: SQLite. Used for storing non-critical, off-chain data like user profiles, achievements, and leaderboard statistics. This data is not essential for the core functionality of the dares themselves but enhances the social and gamified aspects of the app.

Primary Role: The backend's main purpose was initially to handle tasks that are difficult or insecure to perform on the client side. However, with the adoption of Next.js API routes, much of this logic has been migrated to the frontend's server-side environment. The standalone backend now primarily serves as a data store for features that are not yet decentralized.

Blockchain & Smart Contracts: The Decentralized Core Language & Framework: Solidity with Hardhat. Hardhat provides a robust development environment for compiling, testing, and deploying the smart contracts.

Contract Architecture: The system is modular:

DareXModular.sol is the main entry point.

RewardDistribution.sol acts as a secure escrow.

A new Voting.sol contract is deployed for each dare. This modularity makes the system more secure and easier to upgrade in the future.

Decentralized Storage: Proofs on Filecoin Filecoin & IPFS: To ensure that the proofs submitted for dares are permanent and censorship-resistant, we use Filecoin for storage.

Lighthouse SDK (Partner Technology): Integrating directly with Filecoin can be complex. We chose to use Lighthouse as a partner technology to abstract away this complexity. Lighthouse provides a simple SDK that allows our frontend to upload files directly to the Filecoin network (via IPFS). It handles the pinning and storage deals, returning a unique Content Identifier (CID). This CID is what we store on-chain, creating an immutable link to the proof. This partnership was a huge benefit, as it allowed us to implement decentralized storage in a fraction of the time it would have taken to build a custom solution.

The Nitty-Gritty: How It All Pieces Together Authentication Flow: The user journey begins with the World App Wallet Authentication. The Next.js frontend calls our /api/nonce route to get a secure nonce. This is passed to the World App via the MiniKit SDK, which prompts the user to sign the message. The signed payload is then sent to our /api/complete-siwe route for verification. This entire flow is self-contained within the Next.js application, making it clean and efficient.

Creating a Dare: This is a two-step on-chain process, orchestrated by the CreateDare component.

Approval: First, the user must approve the RewardDistribution contract to spend their PYUSD tokens. This is a standard ERC20 token approval transaction.

Creation: Once approved, the user can call the createDare function on the DareXModular contract. This function pulls the approved funds into the escrow and officially records the new dare on the blockchain.

Proof Submission: This is where our partner technology, Lighthouse, shines.

The user selects their proof files in the ProofSubmission component.

These files are sent to a Next.js API route (/api/upload) that uses the Lighthouse SDK to upload them to Filecoin.

The API route returns the CID to the frontend.

The frontend then calls the submitProof function on the smart contract, passing in the dare's ID and the CID.

A "Hacky" but Notable Solution Early in development, we faced a challenge with how to manage the state of the web3 wallet connection across the entire application, especially with the mix of Server and Client Components in Next.js.

Our solution was to create a dedicated providers.tsx file that is a Client Component. This file wraps the entire application and contains all the web3 providers (WagmiProvider, QueryClientProvider, etc.). This approach isolates all the client-side context from the server-rendered parts of the app, preventing a common class of hydration errors. While it feels a bit like a workaround for Next.js's rendering model, it's a stable and widely adopted pattern in the dApp development community for solving this exact problem. It keeps our layout.tsx clean and server-side, while ensuring the client-side components have the context they need to function.