Search projects, hackathons, sponsors and tech

    ← All projects

    Demo

    About

    The problem it solves # 🎯 Pointify ## Background **Project Pointify** was born out of the need to create a **transparent, decentralized, and publicly auditable** loyalty point system. In today’s digital era, many traditional loyalty systems suffer from: - Lack of transparency in point management - Susceptibility to data manipulation - Difficulty in third-party auditing - Limitations to a single platform or merchant Pointify addresses these issues by leveraging **blockchain technology** through **verifiable and auditable smart contracts**. --- ## 📋 Project Overview **Pointify** is a blockchain-based loyalty point system that enables **merchants and users to interact** within a transparent and decentralized point ecosystem. The system utilizes: - **IDRX-Mock Token**: A simulated stablecoin serving as the base currency - **PLT (Pointify Token)**: A loyalty point token that is redeemable - **Treasury System**: Ensures 1:1 backing between PLT and IDRX --- ## 🔄 System Flow 1. **Merchant Registration** → Merchants register and undergo verification 2. **IDRX → PLT Swap** → Merchants convert IDRX to PLT tokens 3. **Reward Distribution** → Merchants reward users with PLT tokens 4. **Point Redemption** → Users redeem PLT for benefits or services from merchants 5. **PLT → IDRX Swap** → Users can convert PLT back into IDRX anytime --- ## 🎯 Problems Solved ### 1. Transparency & Trust **Problem**: Traditional loyalty systems lack transparency **Solution**: All transactions are recorded on the blockchain and publicly auditable ### 2. Interoperability **Problem**: Loyalty points are siloed within platforms **Solution**: PLT can be used across multiple merchants within the same ecosystem ### 3. Backing & Stability **Problem**: Loyalty points have no clear backing or value **Solution**: A treasury system ensures 1:1 IDRX backing for every PLT token ### 4. Fraud Prevention **Problem**: Internal manipulation of loyalty data **Solution**: Immutable smart contracts prevent unauthorized data changes ### 5. Liquidity **Problem**: Loyalty points are hard to convert into real value **Solution**: Users can easily swap PLT back to IDRX --- ## 🚀 Innovation & Roadmap ### Phase 1: Foundation (Current) - ✅ Core smart contract system - ✅ Contract verification on testnet - ✅ Frontend dashboard (Next.js) - ✅ Wallet integration via Xellar ### Phase 2: Enhanced Features - 🔄 Multi-tier loyalty (Bronze, Silver, Gold) - 🔄 Dynamic reward multipliers - 🔄 Cross-chain support - 🔄 PLT listed on DEXs - 🔄 NFT-based rewards ### Phase 3: Advanced Ecosystem - 🔮 DeFi integration: PLT staking & yield farming - 🔮 Governance token for protocol voting - 🔮 Merchant analytics dashboard - 🔮 Public RESTful APIs for integration ### Phase 4: Enterprise Solutions - 🔮 White-label loyalty systems - 🔮 B2B PLT trading marketplace - 🔮 AI-driven reward suggestions - 🔮 KYC/AML compliance tools --- ## 🏗️ Technical Architecture ### Smart Contracts - `TreasuryManager`: Handles merchants, swaps, and rewards - `Treasury`: Stores IDRX reserves for 1:1 backing - `PointifyToken`: ERC20 loyalty point token (PLT) - `IDRXMock`: Simulated stablecoin ### Frontend - **Next.js 14** with **TypeScript** - Web3 integration for blockchain connectivity ### Backend - **NestJS** for API development - **PostgreSQL** for data storage - **JWT** for secure authentication ### Deployment - **Lisk Sepolia Testnet** for development & testing - Verified contracts on block explorer - Multi-network environment configuration --- ## 💡 Value Proposition ### For Merchants - Transparent and trustworthy loyalty infrastructure - No need for complex backend systems - Automatic tracking and analytics via blockchain ### For Users - Loyalty points with real value (IDRX-backed) - Usable across different merchants - Full transparency over owned points ### For the Ecosystem - Standardized loyalty system for Indonesia - Interoperability between different platforms - Foundation for a more transparent digital economy --- **Pointify** represents a bold step toward a **more efficient, transparent, and user-centric loyalty system**, empowered by the blockchain revolution. ``` IDRX_TOKEN_ADDRESS=0x7222435AC83D6c44052eB635112842Da458AEfD8 IDRX_MOCK_ADDRESS=0x7222435AC83D6c44052eB635112842Da458AEfD8 POINTIFY_TOKEN_ADDRESS=0x929f30a023CCA95301ECc5f8b97d7C32862B774f TREASURY_MANAGER_ADDRESS=0xC2ad80E574f02D984E0fD3dA3C4cD221431A8818 TREASURY_ADDRESS=0xfbaBE15d20146a8E15F34bA2a10d409136eEfD62 ``` pitch video: https://youtu.be/AzKAI7SIYGo pitch slide: https://docs.google.com/presentation/d/178G3R2k36DfbKOxJQ_rF4v3M9q1BnaoZBUvZNro2QmQ/edit?usp=sharing Note: to claim IDRX Mock Token you can visit https://dev.pointify.my.id/claim make sure you have sufficient gass fee

    How it's made

    Challenges we ran into Challenges I ran into 1. OpenZeppelin Version Compatibility Issues One of the first major hurdles was dealing with OpenZeppelin contract imports. When attempting to deploy the LoyaltyPoint contract, we encountered: PlainText Error HH404: File @openzeppelin/contracts/security/ReentrancyGuard.sol, imported from contracts/IDRXDistributor.sol, not found. How I solved it: I discovered that OpenZeppelin v5.x changed the import path structure. The ReentrancyGuard contract moved from @openzeppelin/contracts/security/ReentrancyGuard.sol to @openzeppelin/contracts/utils/ReentrancyGuard.sol. After updating the import path, the compilation succeeded. 2. Complex Multi-Contract Architecture Building a loyalty point system with three interconnected contracts (PointifyToken, TreasuryManager, Treasury) required careful orchestration of deployment and initialization sequences. How I solved it: I created a structured deployment script that handles the complex setup: Deploy PointifyToken first with IDRX token validation Deploy Treasury with temporary manager Deploy TreasuryManager with proper references Establish bidirectional contract connections Deploy final Treasury with correct manager permissions 3. Smart Contract Security Vulnerabilities Initially, the registerMerchant function lacked proper access control, allowing anyone to register merchants. How I solved it: I implemented the onlyOwner modifier to restrict sensitive functions to authorized users only, ensuring proper access control throughout the contract ecosystem. 4. Environment Configuration Management Managing multiple contract addresses across different environments (development, testing, production) and ensuring consistency across frontend, backend, and deployment scripts. How I solved it: I centralized all contract addresses in a .env file and created automated deployment scripts that update these addresses after successful deployments. This eliminated manual address management errors. 5. Token Validation and Business Logic Ensuring that only valid IDRX-Mock tokens could be used and that merchants met the minimum balance requirements for registration. How I solved it: I implemented comprehensive validation in contract constructors using try-catch blocks to verify token symbols and added balance checks in the merchant registration process. 6. Package Manager Dependency Conflicts Encountered npm dependency resolution conflicts when trying to install OpenZeppelin contracts. How I solved it: Switched to using pnpm as the package manager, which provided better dependency resolution and workspace management for the monorepo structure. 7. Contract Interaction Flow Complexity The treasury flow involves multiple steps: merchant registration → IDRX to PLT swap → reward distribution → user redemption → PLT to IDRX conversion. Each step required careful state management. How I solved it: I designed a clear state machine with proper event emissions, balance tracking, and validation at each step. Created comprehensive test scripts to verify the entire flow works correctly. Key Learnings: Always check dependency versions and their breaking changes Implement security-first design with proper access controls Use automated deployment scripts to reduce human error Centralize configuration management for better maintainability Test complex flows thoroughly before production deployment Document the architecture for future development and debugging These challenges taught me the importance of thorough testing, proper documentation, and defensive programming practices in blockchain development.