Whitepaper
Discover our technical specifications, future vision, and development roadmap.
Note: The following whitepaper doesn't include sensitive information that could harm the project and be exploited.
Glossary
The following designations and abbreviations are used in this WHITEPAPER:
User - a platform user.
Seller - a User who creates an Exchange Offer.
Active User - A user who has completed at least one P2P transaction.
Passive User - A user who has registered but not yet completed any transactions.
Banned User - A user whose account is restricted from accessing the platform due to violations or inactivity.
Buyer - a User who agrees to an Exchange Offer and creates a Deal.
Digital Asset (short: Asset) - cryptocurrency, such as BTC, ETH, TRX, SOL.
Exchange Offer (short: Offer) - a cryptocurrency exchange proposal that includes an Asset Pair and Total Amount. It can be either a Fixed Amount Offer or a Float Amount Offer.
Fixed Amount Offer (short: Fixed Offer) - an Offer with a fixed price, meaning the Buyer must purchase the entire amount of the Input Asset during the exchange.
Float Amount Offer (short: Float Offer) - an Offer with a flexible price, allowing the Buyer to purchase only part of the Input Asset.
Asset Pair (short: Pair) - a trading pair referring to two assets that can be traded against each other, e.g., BTC/ETH, BTC/SOL, SOL/XMR. The order matters, as BTC/ETH and ETH/BTC are considered different pairs. An Asset Pair consists of an Input Asset and an Output Asset. In Bridgoro, the pairs include: ● BTC/ETH, BTC/XMR, BTC/SOL, BTC/TRX, ● ETH/BTC, ETH/XMR, ETH/SOL, ETH/TRX, ● XMR/BTC, XMR/ETH, XMR/SOL, XMR/TRX, ● SOL/BTC, SOL/ETH, SOL/XMR, SOL/TRX, ● TRX/BTC, TRX/ETH, TRX/XMR, TRX/SOL.
Pair Input Asset - the Asset the participant wants to sell.
Pair Output Asset - the Asset the participant wants to buy.
Offer Total Amount - the total amount of Input tokens the Seller wants to exchange within the Offer.
Trade Deal (short: Deal) - a trade agreement between Users to exchange Assets. It includes the Asset Pair, Exchange Rate, Date, and Status.
Deal Status - the status of a Deal, which can be: ● Created - the Deal is created. ● Accepted - the Seller has accepted the Deal. ● Rejected - the Seller has rejected the Deal. ● Wait For Transfers - the system is awaiting Asset Transfers from the participants. ● Expired - the time for participant actions has run out. ● Completed - the Deal is completed.
Exchange Rate - the exchange rate of the Asset Pair.
Exchange Rate Lock - locking the Exchange Rate at the moment the Deal is created.
Asset Transfer - the transfer of Assets from one wallet to another.
Wallet - a crypto wallet (private key).
Buffer Wallet - a temporary wallet created by the system during a Deal.
Notification - a user notification about an event.
Close Deal - the closure of a Deal, setting its status to Expired, Completed, or Rejected.
Network Fee - the blockchain network fee (paid to validators and miners).
Service Fee - the platform's service fee (paid by Buyer and Seller).
Dumb Fee is the excess amount a user sends beyond the required payment. It's held in the Buffer Wallet instead of being auto-refunded, preventing transaction failures caused by the Escrow Mechanism needing an additional network-fee-dependent transaction.
Fiat - money circulating in the traditional banking system.
Stablecoin - divisible blockchain tokens that may be pegged to Fiat.
BRGX - an internal currency (not blockchain-based, but on a traditional database) used for various platform mechanisms (e.g., gamification, paid features).
Price Margin - the difference between the market price and the price set by the Seller, expressed as a percentage of the market price. It can be either a discount (negative) or a premium (positive).
Withdrawal - the withdrawal of funds, e.g., from a buffer wallet by the Seller when deleting an Offer.
Blockchain Confirmation Time Frame - the timeframe specific to each blockchain within which we check for transfers in the blockchain.
Dead Amount - the amount of an Asset in a wallet equal to or less than the Network Fee required to withdraw the Asset.
Dead Wallet - a wallet containing a Dead Amount.
Dead Wallet Prevention Asset Amount Margin - The minimum balance in a wallet after a transaction to prevent it from becoming unusable.
Monero Rollback Wallet Address - a Monero address for fund returns, as it is impossible to track the sender's address, so the return address must be specified.
Escrow - A mechanism that locks funds until both parties fulfill the transaction requirements.
Deal Timeout - The time limit within which a creation of Deal must be completed.
Rollback Mechanism - A process to return locked funds to their original owners when a transaction fails or is canceled.
Rollback Transfer - the return of funds from a buffer wallet, minus the network fee.
Partial Rollback - Returning only the excess amount of funds beyond the required transaction value.
Collector Module - A system that consolidates dormant funds from inactive wallets for platform use.
Blockchain Adapter - A pluggable module that integrates the platform with specific blockchain networks.
Ephemeral Seed Phrase - A temporary, transaction-specific seed phrase used to generate private keys securely.
Experience Points (XP) - Points awarded to users for completing tasks, leveling up, or engaging in platform activities.
User Level - A rank reflecting user activity and achievements, associated with privileges and restrictions.
Task - A platform-defined objective that grants rewards such as XP or BRGX upon completion.
Repeatable Task - A task that can be completed multiple times on a defined schedule (e.g., daily, weekly).
Notification Module - The system responsible for delivering updates via email or Telegram.
Two-Factor Authentication (2FA) - An additional security layer requiring a second verification step for user login.
Telegram Bot API - An API enabling platform notifications to be sent directly via Telegram.
CAPTCHA - A security feature preventing automated abuse during login, registration, or password recovery.
JWT (JSON Web Token) - A compact, URL-safe token used for secure authentication and session management.
Responsive Design - A design approach ensuring the platform works well on various device sizes and resolutions.
Multilingual Support - The platform’s ability to provide interfaces in multiple languages.
Partial Confirmation - The initial level of confirmation on a blockchain transaction, specific to the blockchain network (e.g., 1 confirmation for BTC).
Full Confirmation - The final level of confirmation indicating that a blockchain transaction is irreversible (e.g., 6 confirmations for BTC).
Level-Specific Privileges - Features or restrictions tied to a user’s current level, such as transaction limits or reduced fees.
Blockchain Adapter API - The interface used by adapters to communicate with specific blockchain networks.
Fee Acknowledgment - A user's consent to platform service fees before initiating transactions.
Service Fee Transparency - The platform's practice of clearly displaying applicable fees to users before transactions.
Overview
Bridgoro project is being developed by a small, independent team of two blockchain enthusiasts. Our mission is simple: create a reliable, censorship-resistant exchange that preserves the core values of crypto-privacy, autonomy, and trust through technology.
Bridgoro is a semi-decentralized exchange because it combines two worlds into one and takes the best of both. The automated escrow system, powered by blockchain adapters and smart contracts, delivers secure and trustless swaps from the decentralized side, while user-friendly matchmaking and rate modules provide the intuitive and smooth experience typical of centralized platforms.
We believe financial privacy is a human right. Traditional KYC/AML systems turn crypto into surveillance finance and expose users to: • Data leaks • Account freezes • Centralized control
Bridgoro eliminates these risks. You stay anonymous. You control your funds. Your transactions stay yours.
Vision and Mission
Vision: Bridgoro envisions a truly decentralized digital economy where users can exchange assets freely, securely, and privately across blockchains - without intermediaries, custodial risks, or regional barriers. We aim to eliminate fragmentation in the multi-chain ecosystem by building a trustless, transparent, and censorship-resistant bridge that empowers individuals to interact directly, not through centralized entities.
Bridgoro aspires to become the backbone of cross-chain interoperability - a neutral, open protocol that any application or user can rely on to link assets and liquidity between chains seamlessly. Our long-term vision is to transform asset transfers into invisible, background processes, making interoperability as natural as using the internet itself.
Mission: Our mission is to create the most secure and efficient peer-to-peer bridge infrastructure by combining decentralized validation, adaptive routing, and privacy-preserving technologies.
Bridgoro is designed to: Empower users to exchange assets directly through smart contracts and on-chain proofs, without intermediaries. • Ensure transparency through auditable logic, verifiable states, and open-source implementation. • Preserve privacy by minimizing traceable data and supporting privacy-first architectures. • Enable interoperability between diverse blockchain networks and standards. • Foster accessibility, simplifying cross-chain transactions so anyone can participate, regardless of technical knowledge or geography.
By delivering a fully autonomous, permissionless bridge, Bridgoro moves the crypto ecosystem closer to a self-sovereign and borderless financial future.
1. General
Bridgoro - a platform for P2P cryptocurrency exchange between registered users. The platform will act as an escrow service, ensuring fair exchanges by locking funds on both sides until confirmation is received that funds from both parties have been transferred and are ready to be sent.
1.1. Features
● Providing a secure and convenient platform for cryptocurrency exchange between users. ● Supporting multiple cryptocurrencies (BTC, ETH, XMR, TRX, SOL), with the capability to add new blockchain networks over time (Blockchain Adapters architecture). ● Integrating an escrow system (guarantee service) for secure transactions. ● Developing a user dashboard to monitor transactions. ● Implementing a user rating and gamification system. ● Adding two-factor authentication (2FA) to enhance security. ● Offering a multilingual interface (Languages will be added soon).
1.2. Application architecture
The application is a distributed platform comprising multiple interconnected modules, including a backend and two separate frontend interfaces: a client-facing web frontend. Below are the technical specifications for each component.
1.2.1. Backend The backend serves as the core of the application, managing business logic, API endpoints, and integration with the blockchain module and databases.
Key Features: ● RESTful APIs for client and admin communication. ● Authentication and Authorization (JWT). ● Data storage and management. ● Integration with blockchain adapters.
Technology Stack: ● Language: Rust. ● Framework: Axum (Rust). ● Database: Postgresql
1.2.2. Client Frontend (Web) The Client Frontend is a web-interfaces that serves as the primary touchpoint for end-users, providing an intuitive and engaging interface for interacting with the platform's functionalities. Adapt seamlessly to different screen sizes and resolutions, including desktops, tablets, and smartphones.
Key Features: ● Account registration, login, password reset. ● P2P Exchange ● Tasks ● User Profile
Technology Stack ● Frontend Framework: React (v18+) ● Programming Language: TypeScript (v5+) ● Styling: Tailwind CSS ● Routing: Tanstack Router ● HTTP Client: Axios ● Form Management: React Hook Form or Formik ● Build Tool: Vite ● Code Quality Tools: ESLint (Airbnb or custom rule set), Prettier for formatting
TypeScript Integration: ● Strongly type all components, props, and state. ● Use interface or type definitions for better readability. ● Enforce strict TypeScript rules (e.g., strict: true in tsconfig).
Responsive Design: ● Responsive design for cross-device compatibility. ● Support screen sizes from 375px to 1920px. ● Compatibility with modern versions of Chrome, Firefox, Safari, and Edge.
1.3. Server
The server forms the backbone of the application, hosting the backend, frontend, and supporting services to ensure uninterrupted and secure access for users and administrators.
Key Features: ● Hosting Backend Services: Ensures the availability and scalability of backend APIs and services. ● Frontend Hosting: Serves static assets for the client and admin frontends, enabling quick load times and a smooth user experience.
1.4. Domains and Cloudflare
To ensure the platform is accessible, secure, and performant, the application uses Cloudflare for DNS management, content delivery, and enhanced security.
Key Features: ● DNS Configuration: Set up Cloudflare as the primary DNS provider and point the domain to Cloudflare’s nameservers. ● SSL/TLS Setup: Enable Full or Full (Strict) SSL mode for secure communication between Cloudflare and the server. ● Caching: Configure caching rules to prioritize frequently accessed resources.
1.5. Third-Party Integrations
To enhance functionality and ensure seamless communication with external systems, the application integrates multiple third-party APIs. These integrations provide features such as real-time exchange rates, blockchain interactions, and user engagement via messaging platforms.
1.5.1. Telegram Bot API Enables interaction with users through Telegram bots, providing notifications, updates directly within Telegram. Bot tokens are securely stored and managed using environment variables. Integration using a Telegram-specific library and Frameworks.
1.5.2. Exchange Rates API Provides real-time and historical exchange rate data for converting between various fiat and cryptocurrencies. Need to implement Coinmarketcap API, Coingecko API and Coinlib API.
1.5.3. Blockchain RPC APIs (BTC, ETH, TRON, SOL, XMR) Enables interaction with multiple blockchain networks to facilitate cryptocurrency transactions, balance inquiries, and smart contract interactions.
1.5.4. Email Delivery Service API To ensure reliable and scalable email communication, the application integrates an email delivery service API. This service handles transactional and marketing emails, providing features such as delivery tracking, template management, and real-time reporting.
2. Application modules
2.1. Authorization Module
The Authorization Module provides secure, user-friendly mechanisms for registration, authentication, and account recovery. It supports traditional email-based registration and login.
2.1.1. Email Registration Allows users to register using an email address (or username) and password. Requirements: ● Validate email format (e.g., using regex). ● Verify the email exists via confirmation (e.g., confirmation email link). ● Password criteria: ○ Minimum length (e.g., 8 characters). ○ At least one uppercase letter, one lowercase letter, one number, and one special character. ● Send a confirmation email containing a unique, time-limited (default: 24 hours) link. ● Allow users to request resending the confirmation email if necessary. ● Store email and password (hashed using a secure algorithm). ● Maintain a status field (e.g., pending, confirmed). ● Notify users of invalid email or password inputs. ● Return appropriate error messages for duplicate email registrations or expired links.
2.1.2. Email and Password-Based Login Users can sign in using their registered email address and password. If user choose Remember me option, system will keep session for 3 days. Requirements: ● Validate the email format using a regex. ● Ensure the password meets the defined complexity requirements (4.1.1.). ● Check if the email exists in the database. ● Retrieve the hashed password for the given email. ● Display error messages for: ○ Incorrect email or password. ○ Inactive accounts (e.g., unverified email). ○ Locked accounts after too many failed attempts.
2.1.3. Password Recovery via Email Enables users to recover access to their account if they forget their password. Requirements: ● Check that the provided email exists in the system. ● Generate a unique, time-sensitive recovery token (default expiration: 24 hours). ● Send an email with the recovery link containing the token. ● Provide a form for resetting the password after clicking the recovery link. ● Validate new password criteria (same as registration). ● Invalidate the recovery token upon successful reset. ● Rate-limit recovery attempts to prevent abuse. ● Allow administrators to configure the link expiration duration and token complexity. ● Notify users of successful password reset via email.
2.1.4. CAPTCHA Verification CAPTCHA is used to prevent automated bots from abusing the registration, login, and password recovery processes. By incorporating CAPTCHA, the system will significantly reduce automated abuse while maintaining a user-friendly experience.Use reCAPTCHA (Google) as the primary CAPTCHA solution, where users complete a "I'm not a robot" challenge for a user-friendly experience. Integration Points: ● Registration form. ● Login form. ● Password recovery form. ● Optional: Repeated failed login attempts trigger CAPTCHA.
2.1.5. Two-Factor Authentication (2FA) Two-Factor Authentication (2FA) adds an additional layer of security to user accounts by requiring a secondary verification step after entering the password. Users can enable 2FA via their account settings. Need to implement Time-based One-Time Password (TOTP) via authenticator apps (e.g., Google Authenticator, Authy). If 2FA is enabled after successfully entering their password, users are prompted to complete 2FA. The system should also allow the user to save the recovery code so that they can restore 2FA in case they lose their phone. Additionally, there should be an option for administrators to disable 2FA if the user loses access.
2.1.6. Email change The Email Change functionality allows users to update the email address associated with their account securely. This process ensures the validity of the new email address and protects against unauthorized changes. Ability to change email depends on User Level. Email change available only for authorized users with enabled 2FA. ● Users initiate the email change request via their account settings. ● Input validation for the new email format (e.g., using regex). ● Generate a unique, time-limited (default: 24 hours) verification link for the new email address. ● Send the verification link to the new email address. ● Upon clicking the verification link, confirm the new email in the system. ● Notify the user of a successful email change via both the old and new email addresses. ● Require re-authentication (e.g., entering the current password) before initiating the email change request. ● Invalidate the verification token upon successful confirmation or after expiration. ● Notify the user via the old email address if an email change request is made. ● Send a final notification to the new email address once the change is confirmed. ● Implement CAPTCHA during the email change request to prevent automated abuse.
2.2. Exchange Rates module
The Exchange Rates Module is a self-contained system that provides up-to-date currency exchange rates to other parts of the application. All exchange rates for assets will be denominated in USD as the base currency. Rates between other assets will be calculated indirectly by referencing their USD values. This module ensures high performance, scalability, and reliability by utilizing a caching system, fallback mechanisms, and robust error handling.
2.2.1. Providers There are 3 Exchange Rates providers: ● Primary - https://coinmarketcap.com/api ● Backup A - https://www.coingecko.com/en/api ● Backup B - https://coinlib.io/apidocs
2.2.2. Caching Implement a caching mechanism for exchange rates to enhance performance and reduce redundant API calls, ensuring the system provides accurate and timely currency conversion data. Caching Strategy: Cache exchange rates locally for a configurable time interval (e.g., 1 minute) to balance freshness and performance.
2.2.3. Failover Module To maintain uninterrupted service, the failover module provides automatic fallback support. Algorithm automatically switches from the primary resource (API endpoint) to a backup resource when the primary becomes unavailable. Monitor the health of the primary API endpoint. If it's unresponsive or returns errors, switch to the backup endpoint. Failover Process: Automatically switch to Backup Provider A if the primary provider fails. Transition to Backup Provider B if both the primary and first backup are unavailable. When the Primary API is operational again, the system should switch back to it.
2.3. Blockchain Module
The Blockchain Module is the orchestrator between application-level requests and blockchain network-specific operations, offering a consistent API interface for all blockchain interactions. It abstracts blockchain-specific complexities and provides a seamless integration layer. The Blockchain Module serves as an intermediary layer that enables interaction with multiple blockchain networks through respective Blockchain Adapters. Its responsibilities include managing configuration, routing requests to the appropriate adapter, and standardizing responses for higher-level application use. Blockchain module should support multi recipient transfers. Multi recipient transfer implemented as high level API in module, and as low level API for each blockchain in Blockchain Adapters.
Key Features: ● Application-level code interacts only with the Blockchain Module. ● The module dynamically routes API calls to the corresponding Blockchain Adapter. ● Blockchain Adapter API - interface to connect Blockchain Adapters
2.4. Blockchain Adapter
A Blockchain Adapter is a pluggable module that implements the Blockchain Adapter API for a specific blockchain network (Ethereum, Bitcoin, Solana, Tron, Monero). Each adapter handles blockchain-specific logic, abstracts complexity, and ensures consistent functionality across blockchains.
2.4.1. Blockchain RPC Use only latest official RPC Specifications: Bitcoin: https://developer.bitcoin.org/reference/rpc/index.html Ethereum: https://ethereum.org/en/developers/docs/apis/json-rpc/ Tron: https://developers.tron.network/reference/json-rpc-api-overview Solana: https://solana.com/docs/rpc Monero: https://docs.getmonero.org/rpc-library/monerod-rpc/
2.4.2. Bitcoin Blockchain Adapter ● Public Key - Derived from the private key using elliptic curve cryptography (secp256k1). ● Address - A hashed and encoded version of the public key, typically using SHA-256 and RIPEMD-160, followed by encoding (e.g., Base58Check). ○ Format: 1... (P2PKH), 3... (P2SH), or bc1... (Bech32 for SegWit). ○ Relation: Public key is not directly used as an address for better security and efficiency. ● Transaction Signing - Sign the transaction using the private key and the secp256k1 signing algorithm via signrawtransaction. Serialize the transaction into the Bitcoin protocol format. Broadcast the transaction using the sendrawtransaction RPC method. ● Balance - Query the balance using the getaddressinfo RPC method. ● Transaction Status - Get transaction status via gettransaction ● Multi recipient transfers - Supported natively by RPC.
2.4.3. Ethereum Blockchain Adapter ● Public Key - Generated using elliptic curve cryptography (secp256k1) and is 128 hexadecimal characters long. ● Address - The last 20 bytes (40 hexadecimal characters) of the Keccak-256 hash of the public key, prefixed with 0x. ○ Format: 0x... (e.g., 0x1234567890abcdef...). ○ Relation: Addresses are shorter representations derived from public keys. ● Transaction Signing - Sign the transaction using the private key and the secp256k1 signing algorithm via eth_signTransaction. Serialize the transaction into the Ethereum protocol format. Broadcast the transaction using the eth_sendTransaction RPC method. ● Balance - Query the balance using the eth_getBalance RPC method. ● Transaction Status - Get transaction status via eth_getTransactionReceipt. ● Multi recipient transfers - Supported by Payment Splitter smart contract.
2.4.4. Tron Blockchain Adapter ● Public Key - Generated using elliptic curve cryptography (secp256k1). ● Address - Derived from the last 20 bytes of the Keccak-256 hash of the public key, prefixed with 41 in hexadecimal (to indicate a Tron address), and finally Base58Check encoded. ○ Format: T... (e.g., T123456789...). ○ Relation: Similar to Ethereum, the address is a derived and encoded form of the public key. ● Transaction Signing - Sign the transaction using the private key and the secp256k1 signing algorithm via signTransaction. Serialize the transaction into the Ethereum protocol format. Broadcast the transaction using the sendTransaction RPC method. ● Balance - Query the balance using the getBalance RPC method. ● Transaction Status - Get transaction status via getTransactionReceipt. ● Multi recipient transfers - As Ethereum is supported by Smart Contracts, but no need to implement it, just make two consistent transactions.
2.4.5. Solana Blockchain Adapter ● Public Key - Represents both the identity and address in Solana. ● Address - Directly uses the public key without any additional transformation. ○ Format: Base58-encoded string (e.g., 4NUX...). ○ Relation: Public key and address are the same. ● Multi recipient transfers - Supported natively by Instructions. ● Specificity - Solana has a Rent fee when you create a wallet. Rent fee should be combined with network fee. ● Balance - getbalance rpc request.
2.4.6. Monero Blockchain Adapter ● Public Key - Monero uses two keys for its stealth address system: a spend key and a view key (both are public keys). They should be combined (concatenated). ● Address - Comprises the spend key, view key, and additional information encoded in a specific format. ○ Format: Begins with 4... (standard address) or 8... (subaddress). ○ Relation: The address is derived using multiple public keys and some cryptographic tweaks, ensuring privacy. ● Multi recipient transfers - Two consistent transactions. ● Transaction Signing - Sign the transaction using the private key and the secp256k1 signing algorithm via sign_transfer. Serialize the transaction into the Ethereum protocol format. Broadcast the transaction using the send_raw_transaction RPC method. ● Balance - Query the balance using the get_balance RPC method. ● Specificity - Two Private and Public keys (View and Spend) ● Transaction Status - Get transaction status via get_transactions.
2.5. User XP and Levels Module
2.5.1 Experience Points XP or Experience Points, is a measure of a user's progress and achievement. XP motivates users to participate in activities and strive for continuous progress. Often tied to levels, XP acts as a currency for progression. Accumulating enough XP pushes users to higher levels or unlocks new features.
2.5.2. User Level A User Level is a classification or rank assigned to a user within a system, typically based on their activity, experience, or achievements. It serves as a way to: 1. Incentivize User Engagement: By offering rewards or unlocking new features as users progress to higher levels. 2. Segment User Privileges: Different levels can have distinct permissions, benefits, or restrictions, such as transaction limits or reduced fees. 3. Gamify the Experience: Makes the platform more engaging by creating a sense of progression and achievement. The User Levels Module is designed to allow admins to define multiple levels with customizable configurations. Users earn XP (experience points) through activities, and their level increases as they reach defined thresholds.
Each level comes with tailored privileges and restrictions for both sellers and buyers, such as: ● Cashback Rewards: A reward in internal currency (BRGX) per 1 USD for successful exchanges. ● Service Fees: Percentage fees applied to sales or purchases. ● Offer & Deal Limits: Constraints on the number and value of offers users can have open at one time. ● Cooldown Mechanics: Penalties for excessive cancellations.
2.5.3. Email Domain Name XP Reward The Email Domain Name XP Reward System is a mechanism designed to incentivize the use of reliable email providers during user registration. This system aims to reduce spam, provide sellers with control over who interacts with their offers. When users register, they earn a specific amount of XP based on their email domain. For example, registering with a well-known and reliable provider like gmail.com might grant 100 XP.
2.6. Gamification Tasks Module
Tasks are interactive challenges or objectives designed to engage users by providing specific goals and rewards. They help structure user activity, encourage participation, and reward achievements. By completing tasks, users earn experience points (XP) and in-app currency BRGX. Tasks are versatile and can adapt to different user scenarios. They include customizable options for descriptions, deadlines, and repeatability. Admins can create tasks with rich content, such as formatted text, images, or embedded media, making them engaging and easy to understand. Markdown is recommended for Rich text edition functions. Tasks support start time and end time parameters. These parameters allow admins to control when a task becomes available and when it expires.Tasks will not be visible or accessible to users before the start time. After the end time, tasks are no longer available, and users cannot claim or complete them.
2.6.1. Claim-Only Task Claim-only task isa category of reward distribution mechanisms within a system that do not require explicit verification steps or the submission of any completion proof by the user. Instead, these tasks can be resolved automatically by allowing the user to simply interact with a designated claim action (Pressing CLAIM button). Before allowing a claim, the system checks if the user is currently eligible. For non repeatable tasks users can claim it only once.
2.6.2. Repeatable Tasks Tasks can be configured as repeatable with flexible recurrence schedules. This behavior mimics repeatable events in tools like Google Calendar, allowing admins to set tasks that reappear based on a specific schedule. For example: ● Daily: Tasks that reset every 24 hours, encouraging consistent daily participation. ● Weekly: Tasks that reset on a specified day of the week. ● Days of week: Choose specific days for weekly repetition (e.g., Mondays and Thursdays). ● Monthly: Tasks that reappear on a particular day of the month. ● Custom Intervals: Tasks that repeat every 2, 3, or more days, based on a defined interval.
2.6.3. Referral Program The Referral Program Module incentivizes users to invite new participants to the platform by providing rewards in the form of XP and BRGX tokens. This program is designed to encourage user growth and engagement, rewarding referrers based on the activities of their referrals. When a referred user registers, the referrer receives a predefined amount of XP as a registration reward. The XP reward amount is configurable in the admin panel, allowing administrators to adjust the incentive based on platform requirements or promotional campaigns. If the referred user becomes active by completing their first transaction (either buying or selling), the referrer is granted a one-time BRGX token reward. Additionally, for every subsequent transaction made by the referred user, the referrer earns a percentage of the transaction value in BRGX tokens. Both the one-time reward and the percentage-based reward values are adjustable in the admin panel, providing flexibility in managing the referral incentives. This modular approach allows the platform to adapt the referral program to different growth strategies and ensure that incentives align with user behavior and platform goals. The referral program's integration with the XP and BRGX systems further gamifies user engagement and creates additional opportunities for community growth and retention.
2.7. P2P Exchange Module
The P2P Exchange Module is the core functionality of the Bridgoro platform, enabling users to securely exchange cryptocurrencies via a peer-to-peer mechanism. This module handles the creation, management, and execution of cryptocurrency trading Deals between platform participants. It includes features for escrow management, offer matching, and deal execution.
2.7.1. Offers This module allows Sellers to create Exchange Offers, which can be structured as fixed (requiring Buyers to purchase the entire input amount) or float (allowing partial purchases). Offers are created with specified price margins relative to the market rate, giving Sellers flexibility in pricing. Required Fields for Offer Creation: ● Exchange Pair: The type of asset the user is offering. ● Offer Type: Float or Fixed ● Offer Total Amount: The quantity of the asset the user is offering in the deal. ● Monero Rollback Wallet: In case of Monero, the user should provide a monero address in case of rollback. ● Receive Wallet Address: The wallet address for receiving the desired asset. ● Minimal User Level allowed to Buy: Users with lower level not allowed to respond to Offer. Need to show Popup: the higher the level you puts, the less chance that his offer will be bought. ● Fee Acknowledgment: Confirmation that the user agrees to any service fees charged by the platform. This process occurs when a Seller creates an exchange offer on the platform. For the offer to become active, the Seller must transfer the required amount of the Input Asset into a Buffer Wallet. This ensures that the assets are secured in escrow, preventing fraudulent or incomplete offers. The system transitions the offer into an "Awaiting Transfer" state until the required assets are confirmed on the blockchain.
Once the seller initiates the transfer from their personal wallet, the platform monitors the blockchain to detect the incoming transaction. It validates the transaction by checking its status and ensuring it meets the minimum confirmation requirements. If the transfer is successful and matches the specified amount, the input asset is locked in the buffer wallet. The offer status is then updated to active, making it visible to potential buyers, and the seller is notified of the successful activation.
If the transfer is incomplete or not confirmed within the set deadline (Configured in Admin panel for each blockchain), the offer is marked as expired. The system notifies the seller about the failure and initiates a rollback process to return any partial funds, deducting applicable network fees. In cases where the transferred amount is insufficient, the system starts a rollback procedure.
Successful transfers activate the seller's offer, while incomplete or failed transfers result in appropriate actions, such as expiring the offer or initiating rollbacks.
2.7.2. Deals When a Buyer accepts an Offer, a Deal is initiated. This Deal has a locked Exchange Rate to avoid price fluctuations and follows a clear status workflow. Deals move through stages such as creation, acceptance, and awaiting fund transfers. Once buyers transfer their respective funds into escrow, the system confirms the transfers on the blockchain and releases the assets to the participants. If either party fails to complete their obligations within the set timeframe, the Deal expires, and funds are returned to their original owners, minus network fees. For Monero transactions, where sender addresses are untraceable, rollback wallets must be specified to facilitate returns.
2.7.3. Escrow System The escrow system is a fundamental component of the platform, designed to ensure secure and trustworthy transactions between buyers and sellers by temporarily holding funds in buffer wallets until all conditions of a deal are fulfilled. This mechanism minimizes the risk of fraud or default by either party, creating a safe environment for peer-to-peer cryptocurrency exchanges. The escrow system monitors the blockchain for all necessary confirmations and ensures that the transaction conditions are met. When both parties fulfill their obligations, such as transferring funds to the escrow and completing any other deal-specific requirements, the platform releases the escrowed funds. The seller receives the buyer's transferred cryptocurrency, and the buyer receives the seller's cryptocurrency, completing the deal. Upon the successful completion of a deal, the escrow system deducts the service fee from the seller's funds before transferring the remainder to the buyer's specified wallet. The fee is calculated as a percentage of the transaction value, which is configurable by platform administrators. For example, if the service fee is set at 2% and the seller’s offer amount is 1 BTC, the platform deducts 0.02 BTC as the service fee and transfers 0.98 BTC to the buyer.
The service fee is displayed transparently to both parties before the deal is initiated. Buyers and sellers can see the applicable fee amount and how it affects their final transfer amounts. This information is included in the offer details and deal confirmation screens, ensuring clarity. In cases where a transaction fails or is canceled (e.g., the buyer does not transfer funds or the deal expires), the service fee is not applied since no funds are transferred between the buyer and seller. Instead, the rollback mechanism returns the locked funds to their respective owners, deducting only the network fees required for the blockchain transaction. The service fee structure can also be dynamically adjusted based on user levels or promotional campaigns. Higher-level users may receive reduced service fees, incentivizing platform engagement and loyalty. This flexibility allows administrators to tailor fee strategies to meet business goals while maintaining user satisfaction.
2.7.4. User Faults If a user provides an incorrect or invalid address for receiving currency, it's essentially their responsibility ("their own fault"). Wherever possible, the system will validate the address (e.g., for networks like Solana, which allow for address verification). However, if the network doesn't support address validation, or the user enters a valid address that is incorrect for their intent (e.g., sending to the wrong wallet they control), the platform cannot take responsibility for the mistake.
2.7.5. Rollback and Partial rollback mechanics The rollback mechanic is a crucial feature designed to handle situations where a transaction cannot be completed, ensuring that funds are returned to the appropriate parties while maintaining fairness and transparency. This mechanism is particularly important in escrow-based systems where funds are temporarily locked during a transaction. When a transaction is initiated, the platform locks the involved funds in a buffer wallet to ensure that neither party can access the funds until the transaction is completed or resolved. If the transaction fails—due to reasons such as an expired deal, insufficient funds, or an invalid wallet address—the rollback process begins. This process identifies the failure point and triggers the necessary actions to return the funds to their rightful owner, minus any applicable fees. For cryptocurrencies like Bitcoin or Ethereum, where transaction origins can be tracked, the rollback simply returns the funds to the sender's address. For Monero, which does not allow tracing of the sender’s address, users must provide a rollback wallet address at the time of transaction initiation. If the transaction fails, the platform sends the funds to this pre-specified address. The rollback process deducts any relevant fees, such as blockchain network fees, before returning the remaining funds. For instance, if the transfer fails because the user sent an insufficient amount to the buffer wallet, the platform deducts the network fee and returns the remainder to the sender. This ensures that no additional financial burden falls on the platform while maintaining fairness to the user. If the transferred funds exceed the required amount, the platform locks the necessary portion for the transaction and initiates a partial rollback for the excess funds. This prevents unnecessary funds from remaining in the buffer wallet and ensures the user's assets are handled efficiently. The rollback mechanic is designed to work seamlessly with the platform's notification system. Users are informed when a rollback is initiated, including details of the amount returned and any fees deducted. This transparency helps build trust and reduces confusion during failed transactions. By implementing a robust rollback mechanism, the platform ensures user funds are secure and properly managed, even in scenarios where transactions cannot proceed as planned. This mechanism upholds the platform’s integrity while mitigating risks associated with incomplete or failed transactions.When a user creates an Offer and sends a larger amount than entered during offer creation, there will be no rollback; the amount they receive will simply be greater. In other words, the system will recalculate the amount of offer.
2.7.6. Deals and Offers cancelation Offers and deals on the platform can be canceled under specific circumstances, depending on their status and the actions taken by the participants involved. For offers, cancellation is primarily available to the seller before any buyer has accepted the offer. If the offer is active but has not been engaged in a deal, the seller can cancel it at any time. This action triggers the rollback mechanism, returning the seller's locked funds from the buffer wallet, minus any network fees. Once an offer has been partially or fully accepted by a buyer, the seller can no longer cancel it directly, as it transitions into a deal. For deals, cancellation is context-dependent and can occur in a few scenarios.
A buyer can cancel a deal only if they have not yet sent funds to the escrow. Once funds are transferred to the escrow wallet, the buyer cannot cancel the deal, as the system locks the funds to protect the transaction's integrity.
2.7.7. Dashboard The rates section prominently displays current cryptocurrency rates in a box labeled "Rates Based on USDT." This section shows exchange rates for various cryptocurrencies like Bitcoin (BTC), Ethereum (ETH), Solana (SOL), Monero (XMR), and TRON (TRX). The rates are presented as static values but are designed to be dynamically updated using Exchange Rates Module. All exchange rate diagrams should be used from https://www.tradingview.com/widget-docs/widgets/charts/ P2P Exchange start widget is dropdown menus for selecting source and target currencies, numeric input fields for entering amounts, and a prominent "Exchange" button to execute the transaction.
After pressing Exchange button the platform queries the Offers database for all available offers matching the selected criteria: ● Source and Target Assets: Offers must match the chosen asset pair (e.g., BTC → ETH). ● Price Margin: The system calculates the price margin set by the Seller based on the live exchange rate from the Exchange Rates Module. ● Offer Type: Fixed or Float offers are displayed based on the Buyer’s selected preferences. ● Amount: The entered amount is compared with available amounts in Float Offers or the fixed total amount in Fixed Offers. ● User Level Restrictions: Only offers accessible to the Buyer's account level are fetched. (If restricted, a popup explains why the offer isn’t available.) The list of matching offers is displayed in a user-friendly table and card format: ● Offer Details: ○ Source Asset (e.g., BTC). ○ Target Asset (e.g., ETH). ○ Exchange Rate (locked). ○ Total Amount (for Fixed) or Available Amount (for Float). ○ Price Margin (percentage above/below market rate). ○ Seller XP Level or Rating. Action Buttons: ● A "Accept Offer" button for each card. ● Tooltips or indicators explaining terms (e.g., price margin, limits, fees The Buyer selects an offer by clicking "Accept Offer"
3. Service Modules
3.1. Collector Module
The Collector Module for inactive wallets is a mechanism designed to utilize leftover or dormant cryptocurrency balances in buffer wallets. Often, small amounts of tokens remain in wallets after transactions, typically because they are too insignificant to cover network fees or are simply forgotten by the user. These small balances can collectively contribute to fundraising initiatives on the platform.
Monitoring Buffer Wallets: The module routinely scans all buffer wallets for residual balances after transactions are completed. These residual balances are typically below a Minimal Dead Wallet Amount Margin, making them impractical for further transactions or withdrawals.
Criteria for Collection: Funds in a buffer wallet are flagged for collection if: ● The remaining balance is below the minimum threshold required for practical use (e.g., less than the network withdrawal fee). ● The wallet has been inactive for a specified period, indicating no intent from the user to reclaim the funds. The system informs users about the Collector Module during registration or through clear terms of service.
3.2. Notification Module
The notification module is designed to handle the delivery of messages via email and Telegram. At its core, the module relies on a centralized Notification Service that interacts with both delivery channels. The module supports advanced scheduling, allowing notifications to be sent immediately or at predefined times. It provides a priority system to handle high-importance messages promptly. User preferences are managed through a dedicated Preference Management System, enabling users to opt-in or out of specific notification types.
3.2.1. Email Notifications For email delivery, the Email Handler integrates with a robust email service provider.
3.2.2. Telegram Notifications For Telegram notifications, the Telegram Handler interacts with the Telegram Bot API. Users must subscribe to the bot for receiving messages, with their chat IDs stored securely in the system.
3.2.3. Notification scenarios ● Registration Confirmation (Email Notification only) ○ Sent after a user registers, with a link to confirm their email address. ● Password Recovery ○ Sent when a user requests to reset their password, including a recovery link. ● Successful Password Reset ○ Sent to notify the user after they successfully reset their password. ● Two-Factor Authentication (2FA) Setup ○ Sent to confirm 2FA setup. ○ Sent with a one-time code when 2FA is triggered during login. ● Login Activity ○ Sent for login attempts from a new device or location. ○ Alerts for failed login attempts exceeding a threshold. ● Account Status Changes ○ Notifications for account bans, suspensions, or reinstatements. ○ Alerts for email changes or other critical account updates. ● Offer Notifications ○ Notifications for expired Offers or Offers with insufficient funds. ● Deal Notifications ○ Sent when a Deal is created, including details like Asset Pair and Exchange Rate. ○ Status updates such as: ■ "Waiting for Transfers" ■ "Transaction Completed" ■ "Deal Expired" ● Fund Transfer Notifications ○ Alerts when funds are locked in escrow. ○ Notifications for successful transfers to the Buyer and Seller. ○ Rollback or refund alerts when transactions fail or are canceled. ● Gamification and XP Rewards ○ Task completion notifications (e.g., "You earned 100 XP for completing a task!"). ○ Level-up notifications (e.g., "Congratulations! You've reached Level 2!"). ○ Reminders for available tasks or tasks about to expire. ● Ban ○ Alerts when an admin or system bans or reinstates a user’s account.
3.3 Knowledge Base Module
The Knowledge Base Module serves as a centralized repository for platform documentation, tutorials, and troubleshooting resources. Built using GitBook, it offers a structured and easily navigable resource that ensures users and administrators have access to the information they need. The knowledge base covers various topics, including user guides, admin manuals, and blockchain-specific instructions, providing comprehensive support for all platform functionalities.
The module leverages GitBook's capabilities to facilitate dynamic updates, allowing the content to be continuously revised to reflect new features, changes, or enhancements. A dedicated change log keeps users informed about updates to the platform, ensuring transparency and alignment with recent developments. Content of knowledge base provided by customers.
4.Roadmap
Bridgoro's development roadmap is structured around three core principles, which are security, scalability, and decentralization. Each phase focuses on delivering measurable milestones that gradually move the protocol from a controlled test environment to a fully autonomous, trustless network.
4.1 Phase I - Foundation (Q2 2025)
Objective: Establish the fundamental architecture, security model, and operational prototype. Milestones: • Finalization of project architecture and module design. • Development of core smart contracts for swap validation and on-chain proof handling. • Implementation of the Blockchain Adapter and Collector Modules. • Launch of the internal testnet. • Integration of initial chains (e.g., Bitcoin, Monero, Ethereum) via adapter-based mechanisms.
4.2 Phase II - Testnet & Community (Q3-Q4 2025)
Objective: Engage the community, test interoperability at scale, and refine user-facing modules. Milestones: • Launch of the public testnet with cross-chain operations. • Release of the Web App Interface (Bridgoro Exchange Platform) with user dashboards and gamification tasks. • Implementation of the Notification and Knowledge Base modules. • Performance optimization and stress-testing of collector and exchange rate modules. • Public bug bounty and incentivized testnet campaign.
4.3 Phase III - Mainnet Launch (Q4 2025)
Objective: Transition to a production-ready, decentralized bridge environment. Milestones: • Mainnet deployment of the exchanging assets. • Full cross-chain integration with top-tier networks (BTC, ETH, XMR, SOL, and others) • Integration of privacy-enhancing mechanisms for transaction routing • Final release of the user application
4.4 Phase IV - Expansion (Q1 - Q2 2026)
Objective: Gradually transition control to the community and expand interoperability. Milestones: • Expansion of bridge support to additional blockchains • API release for third-party integrations and wallet providers • Implementation of stablecoins & fiat.
4.5 Phase V - Ecosystem Growth (Q3 - Q4 2026 and beyond)
Objective: Establish Bridgoro as the leading trustless bridge infrastructure. Milestones: • Strategic partnerships with DEXs, privacy-focused wallets, and DeFi protocols. • Introduction of advanced interoperability layers (NFT and data bridging). • Continuous performance optimization and upgrade cycles. • Global marketing and education campaigns promoting decentralized bridging. • Ongoing community-led feature proposals and protocol extensions.
4.6 Long-Term Vision
The roadmap's ultimate trajectory leads toward Bridgoro's self-sustaining ecosystem, a fully autonomous, decentralized bridge governed by its users, maintained by its validators, and expanded by open-source contributors. Each phase strengthens the protocol's independence, resilience, and usability and advancing the goal of borderless, trustless cross-chain communication.
Last updated