# How do buffer wallets work ### **Escrow Module (Buffer Wallets)** The escrow system is a core module of the platform, purpose-built to guarantee transaction integrity and mitigate counterparty risk in P2P cryptocurrency exchanges. It operates by temporarily locking funds in designated buffer wallets until all deal conditions are verifiably satisfied on-chain. This approach ensures that neither party can unilaterally default or commit fraud, thereby establishing a secure and trust-minimized trading environment. At the backend level, the escrow system continuously monitors the blockchain for required confirmations and conditional triggers. Once both participants fulfill their obligations, such as depositing the agreed assets into escrow and meeting any deal-specific criteria, the system automatically executes the settlement. Upon release, the buyer receives the seller’s cryptocurrency, and the seller is credited with the buyer’s transferred asset, thereby finalizing the transaction. Following successful settlement, the escrow mechanism automatically deducts the applicable service fee from the seller’s funds before disbursing the remainder to the buyer’s destination wallet. Service fees are calculated as a configurable percentage of the transaction value, set by platform administrators. For instance, with a service fee of 0.2% on a 1 BTC trade, the escrow would withhold 0.002 BTC as the platform fee and release 0.998 BTC to the buyer.
Transparency is enforced throughout the process: the service fee, its percentage, and the net receivable amounts are displayed to both participants during deal creation and confirmation. This ensures all parties are fully aware of the fee implications before committing to a trade. If a transaction fails to complete, such as in cases of non-payment, timeout, or cancellation, the escrow initiates a rollback procedure. Locked funds are returned to their respective owners, with only blockchain network fees deducted where applicable. No platform fees are applied to unsuccessful trades. The fee model is further enhanced with support for dynamic adjustments. Administrators may configure tiered fee structures, apply discounts for higher-tier users, or introduce promotional fee reductions. This flexibility enables the platform to align monetization strategies with business objectives while simultaneously incentivizing user retention and long-term engagement. *** ### **Collector Module (Security from Errors)** Buffer wallets are fully automated and secured environments; no team member or third party has direct access to them. All validations, confirmations, and fund releases are executed by autonomous wallet algorithms without human intervention. To safeguard against rare system errors or unexpected interruptions, the platform integrates a Collector Module. This module performs scheduled scans of buffer wallets marked with statuses such as Aborted or Deposit Timeout once per week. If residual funds are detected in any such wallet, the Collector Module consolidates them into a secure collector wallet. Although the development team cannot access individual buffer wallets, this recovery mechanism ensures that in the unlikely event of funds becoming stuck, the team can facilitate their return to the rightful user within a defined timeframe. This architecture strikes a balance between non-custodial fund handling and user protection, ensuring both operational security and reliability. *** ### Rollback and Partial Rollback Mechanics The rollback mechanic is a crucial feature designed to handle situations where a transaction can't 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 network 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 doesn't 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, please refer to the next chapter below: Dumb Fee. 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 can't 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 (ONLY DURING OFFER CREATION); the amount they receive will simply be greater. In other words, the system will recalculate the amount of the offer. But when sending a larger amount while accepting DEALS (offers created by other users), the excess amount is counted as a DUMB FEE and remains in the Buffer Wallet. *** ### **Dumb Fee (for deals only)** If the transferred funds exceed the required amount during the accepting a deal, we classify the difference as a **Dumb Fee**. The exceeding amount remains in the Buffer Wallet until the collector module retrieves it. A user can recover this exceeded Dumb Fee by contacting the support team after a short investigation. **Why a Dumb Fee instead of a Rollback?**\ During internal testing, we encountered several transactional issues specifically stuck transactions because in such cases the Escrow Mechanism would need to perform **three** transactions instead of the usual **two**: 1. Transaction to the recipient 2. Service fee transaction 3. Transaction returning the exceeding amount The Escrow mechanism calculates the network fee only for **two** transactions. Therefore, if the exceeding amount is smaller than the network fee, the entire exchange could fail and get stuck solely due to that extra amount. To avoid this, we implemented the simplest and most stable solution: we treat the exceeding amount as a **Dumb Fee**. *** ### **Deal / Offer Cancellation** The platform implements a controlled cancellation framework for offers and deals to ensure fairness, prevent misuse, and maintain transactional integrity. Cancellation rules vary depending on the transaction stage and the involvement of counterparties. **Offer Cancellation** * Sellers may cancel an active offer at any time before it has been accepted by a buyer. * Upon cancellation, the rollback mechanism is triggered, and the seller’s locked funds are released from the buffer wallet, minus any applicable blockchain network fees. * Once an offer is partially or fully accepted, it transitions into a deal and can no longer be canceled directly by the seller. At this stage, settlement rules for deals apply. **Deal Cancellation** * A buyer may cancel a deal only if no funds have yet been transferred to the escrow wallet. * Once the buyer’s funds are deposited, the escrow locks the transaction to preserve security and enforce obligations, preventing unilateral cancellation. * After this point, the deal must either complete as agreed or proceed through the rollback or dispute-resolution mechanisms, depending on the outcome. This structured approach ensures that cancellations are allowed only during safe, reversible stages of the transaction lifecycle. By clearly defining when and how cancellations can occur, the platform protects both parties’ interests while maintaining the reliability of the trading environment.
*** ### **Dead Wallet Prevention** The Dead Wallet Prevention mechanism safeguards against the creation of unusable residual balances within buffer wallets. Its purpose is to ensure that any remaining funds after a transaction remain practical and transferable, thereby preventing scenarios where small, non-viable amounts are left stranded due to transaction fee overheads. A configurable parameter, referred to as the Minimum Dead Wallet Margin (default: $30 equivalent), is applied to all Float Offer Buffer Wallets. This threshold represents the minimum amount that must remain after a transaction is executed. If the post-transaction balance falls below this margin, the system automatically adjusts the transaction to maintain the threshold. For example, if only $5 would remain in a buffer wallet following a deal, the resulting balance would be impractical, as withdrawal fees would render most of it unusable, leaving the seller with negligible value (e.g., $0.50). By enforcing the Minimum Dead Wallet Margin, the platform prevents such cases, ensuring that wallet balances retain meaningful utility for future use or withdrawal. This feature enhances user experience, reduces operational inefficiencies associated with micro-balances, and ensures sustainable fund management across all active buffer wallets. ***