# Introduction Optimex is a premier Bitcoin finance platform designed to unlock the dormant value of BTC through a trust-minimized architecture, leveraging Bitcoin-native multisigs to eliminate the security risks of wrapped tokens and bridges. Our platform enables users and institutions to *swap, borrow against, or deploy bespoke yield strategies powered by their native BTC holdings*. [*Optimex Swap*](https://app.optimex.com/swap) facilitates high-fidelity, cross-chain execution between native BTC and disparate Layer 1 assets. By utilizing a bridge-less, non-custodial architecture, the protocol eliminates the counterparty and protocol risks inherent in wrapped representations. Institutional participants can initiate trades through our Request for Quote (RFQ) engine, which provides real-time indicative pricing and deep on-chain liquidity for seamless, secure settlement. [*Optimex Borrow*](https://demo.optimex.com/borrow) facilitates liquidity and capital efficiency without divestment through an overcollateralized borrowing module where native BTC collateral is secured in user-participatory multisig vaults. By maintaining an active signing role, users retain co-custodial authority over their collateral, effectively bypassing the taxable disposition risks associated with wrapped assets while accessing stablecoin liquidity at competitive market rates. Built atop Optimex Borrow, our infrastructure empowers users and institutions to deploy *bespoke* [*yield strategies*](https://demo.optimex.com/earn) anchored by their native BTC holdings. In particular, borrowed stablecoin liquidity can be channeled into a curated selection of the most robust and high-performing DeFi protocols whose risk-reward profiles align with users' specific mandates. This model enables a dual-performance engine: investors capture the full upside of Bitcoin’s price appreciation while simultaneously engineering yield through self-directed participation in high-performing lending and liquidity markets. This transforms native BTC from a static reserve into a dynamic capital base, maximizing total returns through a secure, tax-efficient, and trust-minimized framework. ### **Why It Matters?** The demand for **secure, self-custodial** **Bitcoin finance** solutions has been rising rapidly since 2023. The collapse of centralized exchanges has driven significant BTC outflows, underscoring a growing preference among institutions and large holders for non-custodial options that preserve control over their assets. Meanwhile, wrapped Bitcoin solutions like WBTC and custodial rails face **centralization risks** and **increasing regulatory scrutiny** as well as geofencing in key markets like the US, limiting their **scalability** and **accessibility**. **Optimex** addresses these challenges by offering a **Bitcoin-native platform** that unlocks **institutional-grade functionality** without **compromising security** or **decentralization**. # Problem Statement ### **The Problem: Bitcoin’s Centralized Financial Ecosystem** Bitcoin pioneered **decentralized finance**, yet most BTC trading, lending, and custody still rely on **centralized intermediaries** like exchanges and custodians. This contradicts Bitcoin’s ethos and exposes users to: * **Custody Risks** – Users must trust third parties to hold BTC. * **Counterparty Failures** – Bankruptcies can freeze or lose funds. * **Censorship & Regulatory Risks** – Centralized platforms remain vulnerable to intervention. Meanwhile, **DeFi thrives on Ethereum**, but Bitcoin lacks **on-chain financial activity** due to **limited scripting capabilities**. BTC must often be **wrapped or bridged**, compromising its security and decentralization. ### **Our Solution: A Native Bitcoin Finance Suite** Optimex is provisioning a trust-minimized, non-custodial Bitcoin Finance platform that enables users and institutions to utilise: * **BTC-backed Stablecoin Loans:** stablecoin liquidity at competitive rates by using native BTC as collateral in user-participatory multisig vaults. This "co-custodial" approach allows holders to unlock capital without selling or wrapping their BTC, thereby avoiding taxable events and bridge-related security risks. * **Bespoke Yield Strategies**: borrowed stablecoins (anchored by native BTC holdings) can be channeled into curated blue-chip DeFi yield engines. This model allows BTC owners retain full exposure to BTC price appreciation while simultaneously harness yield through self-directed market participation, transforming static BTC into a productive, tax-efficient capital base. **Key Principles** * **Non-Custodial** – Users retain full control of their BTC, eliminating third-party risk. * **Decentralized** – An open system with multiple competing stakeholders ensures resilience and efficiency. With **native BTC Finance**, we unlock Bitcoin’s **full potential**, ensuring trustless, high-liquidity, and censorship-resistant financial services. # Untapped Market With a market cap of \~$2T, Bitcoin is dominating the crypto market with a \~60% share. Yet its share in DeFi is only 0.4% vs 18% for Ethereum — \~60x gap translating to a \~$500B untapped market. Institutions & large BTC holders want liquidity & yield without selling, wrapping, or giving up custody of their BTC. A level of capital efficiency that maintains growth potential while avoiding centralization risks and tax complications of wrapped tokens.
### **The Opportunity** The post-FTX shift toward self-custody, coupled with regulatory constraints on wrapped tokens and custodial rails in markets like the US, has amplified demand for secure, Bitcoin-native lending solutions. BTCFi protocols like Babylon, with $5-6B+ in TVL, highlight the explosive growth potential in BTCFi, yet current offerings primarily focus on staking rather than versatile lending. Optimex targets this opportunity by offering BTC-backed stablecoin loans and yield strategies using self-custodial, Bitcoin-native multisig technology. This enables users to access deep liquidity and compelling rates across DeFi, stablecoins, and real-world assets (RWAs), without counterparty risks or tax complications. With the crypto-backed lending market projected to grow exponentially, Optimex is poised to capture significant institutional and high-net-worth demand, unlocking Bitcoin’s dormant capital for scalable, secure lending in the rapidly expanding BTCFi ecosystem. ### **Limitations of Wrapped Representations of BTC** To bring BTC liquidity into DeFi, many protocols use wrapped representations of BTC, such as WBTC or cbBTC. While these wrapped assets enable Bitcoin holders to participate in DeFi, they introduce systemic risks that Optimex’s native architecture is designed to eliminate: * Centralized Counterparty, Custodial & Censorship Risks: Most wrapped representations rely on a centralized or federated custodian to hold the underlying BTC. This requires users to surrender asset sovereignty to a third-party intermediary, reintroducing the "single point of failure" and custodial risk that native Bitcoin was engineered to address. Besides, the centralised issuers maintain the technical capability to blacklist specific addresses and freeze tokens. This introduces censorship risk into the Bitcoin ecosystem, making wrapped assets incompatible with the requirements of users seeking permissionless and sovereign financial tools. * Taxable Disposition Risk: In many jurisdictions (including the US, UK, and Australia), the IRS and other tax authorities treat the exchange of native BTC for an ERC-20 token like WBTC or cbBTC as a crypto-to-crypto trade. Even if the value remains 1:1, this "wrapping" process triggers a taxable event on any unrealized capital gains. For long-term holders with a low cost-basis and Bitcoin miners, this creates an immediate and unsolicited tax liability. * Transparency & Verification Latency: Wrapped assets often operate as "black boxes" with fragmented proof-of-reserves. Unlike native UTXO-based systems, synthetic representations often suffer from verification latency, preventing users from independently and instantaneously auditing the 1:1 backing of their assets at the protocol level. * Jurisdictional & Regulatory Fragility: As centralized financial products, wrapped tokens are subject to the legal mandates of specific jurisdictions. This exposes holders to potential asset freezes, administrative seizures, or sudden regulatory shifts that could impair the issuer's ability to facilitate redemptions. # Primary Building Blocks Optimex is built on a foundation of core infrastructure components that power all products across the platform. These building blocks ensure security, decentralization, and seamless cross-chain operations for Bitcoin-native finance. The Optimex protocol relies on four fundamental components that work together to enable trustless, non-custodial Bitcoin DeFi: * **Native Bitcoin Vault**: Secure BTC custody using Bitcoin-native multisig technology that enables seamless on-chain interactions while users retain full self-custody. * **Decentralized Settlement Committee**: A trust-minimized network of validators responsible for transaction finality, dispute resolution, and co-signing vault operations. * **L2 as a Communication Layer**: An EVM-compatible Layer 2 network that coordinates trades, records protocol events, and synchronizes all stakeholders. * **Optimex Staking**: The validator management system that governs how Node Operators join and participate in the Settlement Committee. Operators must stake collateral to become validators, aligning their incentives with honest behavior through bonding, slashing, and governance mechanisms. These components work together: the Native Bitcoin Vault holds user BTC securely, the Settlement Committee validates and co-signs transactions, and the Staking system ensures committee members are economically aligned through bonded collateral. This shared infrastructure powers both Optimex Swap and Optimex Borrows, ensuring consistent security guarantees across all products. # Native Bitcoin Vault The **Optimex Vault** is a non-custodial escrow mechanism that temporarily holds users' assets while trades are in process. It ensures security, decentralization, and compatibility across multiple blockchains, including Bitcoin, Ethereum, and Solana. For Bitcoin, **Optimex** has designed a **native Bitcoin vault** using existing Bitcoin scripting, making it fully compatible with the Bitcoin network. This vault acts as a **non-custodial "smart account"**, allowing users to manage assets and execute DeFi actions directly on Bitcoin. ### Key Features * **Multisig Authorization**: Uses a **2-of-2 multisig**, where the two signers are the **User** and the **Validator Network**. * **Timelock Security**: If no action is taken within a specified time **T**, the user can reclaim funds unilaterally. ### Vault Functionality 1. **Trade Execution (Within T-Hour Window)** * User deposits BTC into a Pay To Taproot (P2TR) address controlled by the Vault. * A transaction can be authorized using two **ECDSA signatures**—one from the **User** and another from the **Validator Network**. * The Validator Network utilizes **tECDSA** (threshold ECDSA), ensuring no single party has full control over the private key. 2. **Timelock Protection (After T-Hour Window)** * If no trade execution occurs within time **T**, the user can reclaim their BTC using only their own signature. * This ensures that user funds remain secure and cannot be held indefinitely. ### Bitcoin Vault Script In the following, we give more technical details on our implementation of the **Bitcoin Vault** using **Taproot (P2TR)**. The Bitcoin Vault is essentially a Script that facilitates conditional BTC custody through a Taproot address. The Taproot output can only be spent through a script spending paths. The key spending path is disabled by using the "Nothing Up My Sleeve" (NUMS) point as internal key.\ \ The script spending paths comprise of:
1. **Multi-sig spending Path** ` OP_CHECKSIG`\ ` OP_CHECKSIGADD`\ `OP_2 OP_NUMEQUAL` Where: * `SettlementCommitteePK`is the Settlement Committee's tECDSA public key * `UserPK` is the User's pubic key Example transaction that spends the Vault via the Multi-sig spending path can be found [here](https://mempool.space/tx/46922e7a8f3c93434b58ce0f79fb4e711313d468a5f4ea60f120c411f5d93964). 2. **User-controlled withdrawal after timelock Path** ` OP_CHECKSEQUENCEVERIFY OP_DROP`\ ` OP_CHECKSIG` Where: * `TimelockBlocks` determines the Vault's expiry time. It is set to 144 blocks which is approximately 24 hours. After this duration has elapsed, the User can close the vault and withdraw the deposit from the vault at their discretion. * `` is the User's pubic key Example transaction of the user close vault and withdraw after 144 Bitcoin blocks can be found [here](https://mempool.space/tx/afc088196f1b3fdffdf16983f89ef40c01dabbea09657b59464b61f907ea75a3). ### Cross-Chain Vault Instances Each blockchain **Optimex** supports has its own **Vault instance**, designed to meet its security and smart contract capabilities: * **Bitcoin**: Uses **Bitcoin Script** to enable non-custodial, time-locked asset management. * **Ethereum & Solana**: Implemented as **smart contracts**, allowing users to deposit assets and specify authorized recipients for trade settlements. ### Advantages of Optimex Vaults * **Security**: * The combination of **standard ECDSA and tECDSA** minimizes the risk of key compromise. * The **Settlement Committee’s tECDSA setup** ensures no single entity controls the private key. * Users always have a fallback mechanism to reclaim funds after a timeout. * **Non-Custodial & Decentralized**: * Users retain control of their assets, even during trades. * Transactions require **multi-party authorization**, ensuring trustless execution. * **Bitcoin Compatibility**: * Uses standard Bitcoin Script opcodes, ensuring full compatibility with all Bitcoin nodes, wallets, and services. * The **tECDSA implementation is invisible to the Bitcoin network**, making the Vault seamless and efficient. # Decentralized Validation Network The **Decentralized Validation Network** is responsible for monitoring trades and ensuring that the **Optimex** Vault settles assets correctly when all trade conditions are met. It consists of **Multiparty Computation (MPC) nodes**, which collectively authorize transactions using a **threshold signature scheme**. ### Structure & Security * **MPC Nodes**: The Validation Network initially consists of **three MPC nodes**, producing a **2-of-3 threshold (tECDSA) signature** for trade settlement. * **Epoch-Based Key Refresh**: To enhance security, MPC nodes and their cryptographic keys are refreshed at regular epochs. * **Security Deposits & Slashing**: * Each node must **stake a security deposit**, ensuring economic accountability. * Nodes are **slashed** if they deviate from protocol rules, such as failing to sign in time or blocking valid settlements. * The combined stake of all nodes must always be greater than the value of assets temporarily controlled by the Vault during trades. * **Scalability & Risk Mitigation**: * Because assets remain under Vault control only during the trade process and are settled immediately, the Validation Network can **facilitate billions in trading volume** with reasonable security deposits (e.g., **$10M–$20M per node**). The Validation Network's decentralized design ensures **trustless trade execution, high security, and economic alignment among participants** in the **Optimex** ecosystem. #### Current Deployment The Validation Network currently comprises three nodes operated by three independent teams: * [**AltLayer**](https://altlayer.io/) **team** * [**SubWallet**](https://www.subwallet.app/) **team** * **Optimex team** This multi-party setup ensures no single entity controls the committee, providing decentralization from day one while the network scales toward broader validator participation through permissionless staking. # L2 as a Communication Layer **Optimex** introduces a dedicated **Layer 2 (L2)** to coordinate interactions between key participants, ensuring transparency and security across the system. The L2 records **DeFi activities**, manages **Settlement Nodes’ security deposits**, and enforces **slashing penalties** for protocol violations. In most cases, users do not need to interact with the L2 directly. Instead, it serves as a **backend coordination layer** for **Validation Network Nodes, Market Makers, and other stakeholders**, ensuring a **shared system view** and enforcing **economic security** against bad actors. # Optimex Staking **Optimex Staking** is a decentralized validator management system that enables **Node Operators** to stake collateral (native tokens or ERC-20s) and participate in the **Optimex Protocol** as validators. The system provides a complete lifecycle for validator onboarding, staking, registration, and exit. It integrates with **Chainlink Functions** to enable off-chain challenge verification while maintaining on-chain enforcement, ensuring validators remain accountable and the network stays secure. ### Why Staking Matters Inside Optimex * Aligns validator incentives by requiring bonded collateral before they can participate in Optimex execution. * Gives governance fine-grained controls to freeze, slash, or unlock capital in response to network events. * Provides a clean lifecycle for node operators: onboard, stake, register, serve, exit, and withdraw. * Extends the core staking flow with a Chainlink-powered challenge system to arbitrate verification off-chain but enforce resolutions on-chain.
### Validator Onboarding and Offboarding Procedure
Validator Onboarding Procedure
The following outlines the step-by-step process for becoming a **`Validator`** in the **Optimex Staking Protocol**: **Step 1: Deploy a `Staker` Node:**\ Call `createStaker(owner)` on the `StakerManager` contract, where `owner` is the Ethereum wallet address. A new `OptimexStakingNode` contract is deployed and initialized with the provided address as the owner. The node starts in the `INACTIVE` state.\ **Note:** Anyone can deploy an `OptimexStakingNode`, but only the `owner` can configure and operate it. **Step 2: Configure deposit tokens:**\ As the node owner, call `setToken(token, true)` on your Staker Node for each token you want to use as collateral.\ Supported tokens: * Native token (`ETH`): represented as `address(0)`. * ERC-20 tokens: provide the token contract address. **Step 3: Set `metadataURL` (optional):**\ Call `setMetadataUrl(url)` on your Staker Node to provide an external URL for retrieving the node’s metadata. This metadata can be used by off-chain systems to display information about your validator node. **Step 4: Deposit collateral:**\ Call `deposit(token, amount)` for each token you want to stake. Tokens are deposited into your Staker Node contract. They are in a **`deposited`** state and can still be withdrawn until they are **locked**. Ensure you deposit sufficient collateral to meet the minimum staking requirements before proceeding to registration. **Step 5: Request registration:**\ Call `register()` on your Staker Node contract. Ensure the following: * Your node is in the `INACTIVE` state. * The system is not in a global freeze state (`frozenAll` must be `false`). * You do not have a pending request that has not yet expired. A registration request is created with an expiration timestamp (`currentTime + requestWindow`). You cannot submit another request until the current request window expires. **Step 6: Wait for Governance approval:**\ Wait for `OptimexStakingGovernance` to review and approve your registration request. Upon approval, Governance calls `approveRegistration(staker, tokens, amounts)` on the `ValidatorManager` contract. Governance specifies which tokens and amounts to lock from your deposits. The approval must occur before your request expires.\ After approval: * Your deposited tokens are locked (moved from the **`deposited`** state to the **`staked`** state). * Your node status changes from `INACTIVE` to `ACTIVE`.\ **Note:** If your request expires before approval, you must submit a new registration request. **Step 7: Complete `Validator` onboarding:**\ Your node is now `ACTIVE`, and you can begin performing validator duties. Your staked tokens remain locked and cannot be withdrawn. Governance can freeze your node if issues arise. Governance can slash your staked tokens for violations. You can request to exit the validator set at any time.
Validator Offboarding Procedure
The following outlines the step-by-step process for exiting the validator set and withdrawing your staked assets in the **Optimex Staking Protocol**. **Step 1: Request `Exit`:**\ Call `exit()` on your Staker Node contract. Ensure the following: * Your node is in the `ACTIVE` state. * The system is not in a global freeze state (`frozenAll` must be `false`). * You do not have a pending request that has not yet expired. * An exit request is created with an expiration timestamp (`currentTime + requestWindow`). You cannot submit another request until the current request window expires. The `requestWindow` is a cooldown period that prevents rapid request spam and ensures requests have a valid time window for governance review. In most cases, it also provides time for keyshare updates and cleanup of pending duties. **Step 2: Wait for `Governance` approval:**\ Wait for `OptimexStakingGovernance` to review and approve your exit request. Upon approval, Governance calls `approveExit(staker)` on the `ValidatorManager` contract. The approval must occur before your request expires. After approval: * Your node status changes from `ACTIVE` to `INACTIVE`. * Your collateral remains in the **`staked`** state, and an unlock timestamp is set (`currentTime + requestWindow`). * Your tokens remain locked until the unlock timestamp is reached. This waiting period provides a security buffer that allows for final checks, such as community disputes or challenges. **Note:** If your request expires before approval, you must submit a new exit request. **Step 3: Wait for `unlock` period:**\ Wait until the unlock timestamp is reached. You cannot unstake your tokens until this timestamp has passed. You can monitor the unlock timestamp using `unlockTimestamps(staker)` on the `ValidatorManager` contract. Once `block.timestamp >= unlockTimestamp`, you can proceed to unstake. **Note:** `Governance` or `Slasher` can extend the unlock timestamp if needed by calling `extendUnlock()`. This adds another `requestWindow` period to the unlock time. The unlock timestamp can be extended before it expires. **Step 4: Un-stake your tokens:**\ Call `unstake(tokens)` on your Staker Node contract, where `tokens` is an array of all token addresses you want to unstake. Ensure the following: * Your node is in the `INACTIVE` state. * The current timestamp is greater than or equal to the unlock timestamp. * The system is not in a global freeze state (`frozenAll` must be `false`). **Notes:** * You must unstake the **full amount** of each token; partial unstaking is not supported. * You must specify **all** staked tokens in a single call. * The unlock timestamp is cleared after unstaking. **Results:**\ Your staked tokens are unlocked (moved from the **`staked`** state to the **`deposited`** state). Tokens are now available for withdrawal. **Step 5: Withdraw your tokens:**\ Call `withdraw(to, token, amount)` for each token you want to withdraw. Tokens are transferred from your Staker Node contract to the specified recipient address. **Note:** You can withdraw tokens in multiple transactions if needed. Withdraw only what you need, as any remaining deposited tokens can stay in the contract for future use.
Validator Slashing & Challenge Procedure The following outlines the step-by-step process for submitting a challenge, handling global freeze/unfreeze, and executing the slashing procedure in the **Optimex Staking Protocol**.
**Step 1: Submit a `Challenge` request:**\ The **Challenger** calls `challenge(typeOfChallenge, gasLimit, request)` on the `ChallengeForwarder` contract. A **challenge fee** is collected upon submission. A challenge request is sent to the `FunctionsRouter` contract operated by **Chainlink**. *Off-chain process (by **Chainlink**):*\ The request is forwarded to the **Chainlink DON** for off-chain verification. A verification script analyzes the challenge data and determines whether the validator’s behavior is malicious. **Step 2: Chainlink DON response:**\ The **Chainlink DON** calls `fulfillRequest(challengeId, response, err)` on the `ChallengeForwarder` contract once verification is complete. The response either: * Confirms the validator’s misbehavior, or * Rejects the challenge. The response is recorded and stored in the `challenges[challengeId]` mapping in the `ChallengeForwarder` contract. If the proof is confirmed as **true**, the freezing and slashing phase is triggered. **Step 3: Emergency Freeze — Freeze All `Stakers`:**\ Upon confirmation from the **Chainlink DON**, the `ChallengeForwarder` calls `freezeAll()` on the `ValidatorManager` contract. The global `frozenAll` flag is set to `true`, effectively freezing all stakers: * No staker can submit registration or exit requests. * No staker can perform unstaking actions. *Note:* An owner of a staker contract can still withdraw tokens that are **not** in the `staked` (locked) state. **Step 4: `Governance` decision — Freeze / Unfreeze / Slash:**\ The **Governance** interacts with the `ValidatorManager` contract to perform the following actions: * Calls `unfreeze(stakers)` to unfreeze innocent stakers. * Calls either: * `freeze(stakers)` to freeze misbehaving stakers, or * `slash(staker, tokens, amount)` to penalize misbehaving stakers. On freezing: Each specified staker’s status changes from `ACTIVE` to `FROZEN`.\ On slashing: The specified stakers have their staked tokens slashed, and the slashed tokens are transferred to the `OptimexStaking` contract for further handling. Finally, it calls `unfreezeAll()` to clear the global `frozenAll` flag so normal operations can resume: * Stakers with `ACTIVE` status can resume normal validator duties. * Stakers with `FROZEN` status remain individually frozen. **Step 5: Compensation:**\ Calls `distribute(to, token, amount)` on the `ChallengeForwarder` to refund the challenge fee to the **Challenger** who successfully submitted a valid challenge. Calls `distribute(to, token, amount)` on the `OptimexStaking` contract to compensate affected victims or the **Challenger**, as determined by governance.
# Optimex Swap Optimex Swap enables you to quickly and securely swap assets both from and to BTC directly on-chain, without bridges or wrapped tokens. Simply select your trading pair, specify the amount, and review the indicative quote provided by our RFQ engine. Deposit your BTC or the other asset into a secure, native multisig vault, locking in a committed, slippage-free quote from professional market makers. After your deposit confirms, you can finalise the swap. Assets are then exchanged seamlessly and securely. Your asset moves directly from your custody only at the final settlement step, ensuring full control at every stage. **Why RFQ Over AMMs?** Unlike **Automated Market Maker (AMM)-based** protocols, which are prone to **slippage and Miner Extractable Value (MEV) attacks**, Optimex offers BTC trades using the **Request-For-Quote (RFQ)** model which provides: * **No MEV & No Slippage**: Predictable pricing and execution. * **Built-in Rate Aggregation**: Best available rates across market makers. * **Smart Order Routing**: Large trade splitting and routing across multiple market makers, minimizing impact on market depth. # User Guide Optimex Swap enables you to quickly and securely swap assets both from and to BTC directly on-chain, without bridges or wrapped tokens. Simply select your trading pair, specify the amount, and review the indicative quote provided by our RFQ engine. Deposit your BTC or the other asset into a secure, native multisig vault, locking in a committed, slippage-free quote from professional market makers. After your deposit confirms, you can finalise the swap. Assets are then exchanged seamlessly and securely. Your asset moves directly from your custody only at the final settlement step, ensuring full control at every stage. {% embed url="" %} In the following, we will walk you through how to conduct cross-chain swap in a native and non-custodial manner. {% content-ref url="/pages/GOLNQv8YDu0sqvxZKIS8" %} [Connect your Wallet](/optimex-revolutionizing-bitcoin-finance/optimex-swap/user-guide/connect-your-wallet) {% endcontent-ref %} {% content-ref url="/pages/jgKtdKXKhb0vh7eIvV4a" %} [Initiate Swap Request](/optimex-revolutionizing-bitcoin-finance/optimex-swap/user-guide/initiate-swap-request) {% endcontent-ref %} {% content-ref url="/pages/3b9wGcmnJ8d42HDvfcbW" %} [Confirm and Sign](/optimex-revolutionizing-bitcoin-finance/optimex-swap/user-guide/confirm-and-sign) {% endcontent-ref %} {% content-ref url="/pages/dNv2cedj78Dg0CnTLpJV" %} [Track Swap Progress](/optimex-revolutionizing-bitcoin-finance/optimex-swap/user-guide/track-swap-progress) {% endcontent-ref %} # Connect your Wallet In order to use services on the [Optimex platform](https://app.optimex.com/), users first need to connect their Web3 wallet. It is worth noting that the Swap feature on the Optimex platform is cross-chain; it deals with two separate wallet addresses, each for a particular asset. In the following, let us refer to the asset you want to sell as base asset, and its corresponding wallet base wallet, and the asset you want to buy (or receive) as quote asset, and its corresponding wallet quote wallet. For each Swap on the Optimex platform, the base wallet is required to be connected. To connect the base wallet, click on the Connect Wallet button at the top right corner of the page.
The wallet selection pop-up will appear, prompting you to select your preferred Web3 wallet to connect to the Optimex platform as the base wallet for your Swap. Before authorising the connection, you’ll be required to tick the checkbox confirming that you’ve read and agree to the Terms of Use and Disclaimers. After agreeing, authorise the connection in your chosen Web3 wallet’s UI.
***Funding your wallet***: On-chain transactions typically require a network transaction fee payable in the chain’s native currency (e.g., BTC on Bitcoin, ETH on Ethereum, SOL on Solana). Please ensure your base wallet has sufficient funds to cover this fee.
# Initiate Swap Request Once the base wallet is connected, you can proceed to initiate the Swap request:
* Choose the swap pair by indicating your preferred base asset and quote asset. * Specify your swap amount denominated in the base asset.
Fill in the recipient address manually or connect your recipient wallet and click on ‘Use My Wallet’, which will automatically insert your recipient address. Double-check to ensure all details are correct before proceeding. The Swap is configured with default slippage settings. If you wish to adjust this, click on the icon at the top right corner of the Swap window and specify your custom settings. Details of the Swap (e.g., Minimum output amount, allowed slippage, protocol fee, etc.) are listed in the ‘Swap details’ drop-down menu. Once everything is correct, proceed by clicking on the Review button, which will bring you to a summary of your Swap. # Confirm and Sign Once you have confirmed all the swap details on the Optimex platform UI, the final steps are to authenticate the swap and sign-off the transfer on your Web3 wallet:
* Authenticate Swap request: Your connected base wallet UI will prompt you with a signature request. This signature is to authenticate the swap with specific swap details you saw earlier in the previous screen. No fund nor asset is moved with this signature. * Token approval (applicable for ERC-20 token): If your base asset is an ERC-20 token (e.g., USDC, USDT or WBTC on Ethereum), your base wallet UI may prompt you to grant approval. This is a common practice for DeFi platforms dealing with ERC-20 tokens. * Confirm swap: Finally, the base wallet UI will request your signature to transfer the indicated amount of base asset to Optimex Vault associated with the Swap. This transfer officially puts the Swap in progress. The next parts are on Optimex’s Solver and PMM to handle. # Track Swap Progress After you confirm the deposit transaction, while no more action is required from you, you will be taken to the next page that shows swap progress. In this page, you can track the status of your deposit transaction on the blockchain associated with your base asset, if your swap request is picked up and served by some Market Markers, and once it is, the status of payment transaction from the selected Market Market to your quote wallet.
# How It Works **Optimex** Swap is a decentralized, non-custodial RFQ (Request-for-Quote) Bitcoin trading protocol designed for high liquidity and fast settlement. It ensures optimal trade execution through rate aggregation at the protocol level. Large trades are intelligently split and routed across multiple market makers, eliminating slippage and MEV risks. **Optimex** Swap operates on its own ledger—an EVM Layer 2 (L2)—which acts as a public bulletin board to coordinate various stakeholders. This design enhances transparency while maintaining decentralization. To participate, stakeholders must meet security deposit or staking requirements. Users and market makers retain full custody of their assets at all times, ensuring a **non-custodial** trading experience. Additionally, key services and stakeholders operate in a **decentralized** and permissionless manner, reinforcing trust and transparency. ### Architecture **Optimex Swap** enables secure, non-custodial trading between **Bitcoin and Ethereum**, as well as **other EVM-compatible chains**. The architecture supports two trade paths, depending on the user’s destination: **1. Bitcoin ↔ Ethereum (Direct Swap via Optimex Protocol)** Trades between BTC and assets on **Ethereum Mainnet** (e.g., ETH, WETH, USDC, USDT) are executed entirely within the Optimex protocol. The process is secure, efficient, and decentralized thanks to the following innovations: * [**Native Bitcoin Vault**:](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault) Secure BTC custody mechanism enabling seamless on-chain interactions. * [**Decentralized Settlement Committee**:](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/decentralized-validation-network) A trust-minimized approach to transaction finality and dispute resolution. * [**L2 as a Communication Layer**:](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/l2-as-a-communication-layer) The **Optimex** ledger (EVM L2) coordinates trades, records key events, and ensures a transparent yet efficient trading process.

BTC-to-ETH Swap Flow

**2. Bitcoin ↔ EVM-Compatible Chains (Swap + Across Bridge)** For swaps between **BTC and assets on EVM-compatible chains** (e.g., Arbitrum, Optimism, Base, BSC), Optimex combines its native Bitcoin **↔** Ethereum swap (explained above) with [**Across Bridge**](https://across.to/across-bridge). In particular, if the base asset is BTC, the swap is carried out on Optimex Swap first, resulting in a quote asset on Ethereum Mainnet. The quote asset is then bridged to the user's selected EVM-compatible chain via Across Bridge. Alternatively, if the base asset is on an EVM-compatible chain, it is bridged to Ethereum Mainnet via Across Bridge before being swapped into BTC via Optimex Swap. # Market Makers Market makers play a crucial role in **Optimex**, providing real-time **rates** and settling trades **directly with users**. Unlike traditional models, market makers **do not need to commit liquidity on-chain**; they can **maintain their inventory elsewhere** and only move assets when a trade is confirmed. To ensure reliability and prevent **Sybil attacks**, market makers must **stake a security deposit**, which also acts as an incentive to fulfill trades. Initially, **Optimex** will launch with a **select group of reputable market makers** for efficiency. In the future, a **reputation system** will track market makers’ success rates—measuring the ratio of **successful trades to total trades**—with a similar system applicable to solvers.
Meet our Market Makers
*Tokka Labs is a leading proprietary trading firm specializing in high frequency onchain trading strategies. Known for its rigorous research, advanced technology, and collaborative approach, the firm designs and operates its own trading systems to serve as market makers, searchers, and solvers for top DeFi protocols, cross-chain bridges, and intent-based frameworks. With over $50 million in capital deployed across more than 70+ venues, Tokka Labs delivers dependable liquidity and drives market efficiency across some of the most active and complex onchain ecosystems.*
*Kipseli Capital is a pioneer in on-chain market making, providing liquidity on-chain since 2018. Having processed billions in on-chain volume, they consistently offer deep liquidity at competitive rates. Kipseli is integrated with all major RFQ protocols and aggregators, and has deployed more than $25 million in capital on the Ethereum mainnet alone. Their robust infrastructure ensures high reliability and uptime.*
In addition to the **market makers** already onboard, we’re actively bringing in **more top-tier market makers** to further enhance our **service quality** and ensure the **most competitive rates** in the market. # Solver A **Solver** acts as the **bridge between users and market makers**, ensuring efficient trade execution. It receives user requests, fetches rates from market makers, and determines the **best rate and routing strategy**. Beyond rate aggregation, the Solver **optimizes execution** by **splitting trades across multiple market makers**, ensuring users receive the most competitive pricing with minimal slippage. # Execution Flow This section outlines **Optimex’s swap execution process** using an example where a user swaps **BTC for ETH** while maintaining **full custody** of their BTC—without relying on intermediaries or wrapped assets. ### Fixed-Rate Swap 1. **BTC Deposit & Swap Intent** * The user deposits BTC into the **Optimex Vault** on the Bitcoin network. * This deposit signals their commitment to swap, though they can reclaim their BTC after a **timelock (T)** expires (e.g., 24 hours). 2. **Quote Request & Selection** * The user requests quotes from **market makers (MMs)** via the **Solver**. * Since BTC is already in the Vault, MMs provide **competitive, market-aligned quotes**. * The user selects the best quote and **confirms the swap** by signing a transaction that authorizes the Vault to send BTC to the chosen MM (pending final approval). 3. **ETH Payment & Swap Settlement** * The MM sends the ETH payment to the user based on the agreed rate. * Once confirmed on-chain, the **Settlement Committee authorizes** the Vault to release BTC to the MM, completing the swap. #### **Security Mechanisms** If the **Validator Network or MM acts maliciously**, **Optimex** ensures fairness through: * **Blocking BTC Release**: If the MM doesn’t send ETH, the **Settlement Committee’s security deposit** covers user losses. * **Unauthorized BTC Transfers**: If the Committee colludes with the MM to take BTC without payment, both the **MM and the Committee** are penalized. * **Swap Failure**: If the MM fails to fulfill the swap, part of its **security deposit is slashed** and paid as compensation to the user. The user can then reclaim BTC after the timelock expires. ### Turbo Swap **(Faster Settlements)** The Fixed-Rate Swap **requires Bitcoin confirmations**, which can take **\~30 minutes**. To streamline execution, **Optimex enables an "Turbo Swap"**, allowing users to **pre-confirm swaps** while their BTC deposit is still pending. 1. **Indicative Quotes & Pre-Confirmation** * The user requests **indicative quotes** from MMs via the Solver. * Solver selects the best two quotes (from two MMs) and informs the User. * The User sets a **minimum acceptable rate** and an **expiry time** for the swap. * The user deposits BTC into the Vault and **pre-signs a transaction** allowing settlement to one of the selected MMs if conditions are met. 2. **Final Quote & Execution** * Once the BTC deposit is confirmed, the Solver fetches **committed, binding quotes** from the selected MMs. * If a quote meets the **user’s minimum acceptable rate**, the swap is executed immediately. This **reduces wait times** and enables **one-shot swap execution**, improving the user experience. The **number of pre-signed market makers can be increased beyond two** for additional flexibility.
# Trade Life Cycle The `Optimex Protocol` enables secure cross-chain asset transfers through a structured, multi-step trade process that includes user deposits, market maker (`PMM`) execution, and final settlement. Each trade progresses through clearly defined stages and is continuously monitored by a decentralized Multi-Party Computation (`MPC`) network, ensuring consistency, validation, and reliable failure recovery.

Optimistic Swap - Trade Life Cycle

### Trade Completion States Each trade concludes in one of two final states: * `Completed` – The trade successfully progresses through all required lifecycle stages and the recipient receives the intended asset. * `Refunded` – The trade encounters an issue that prevents completion. The protocol safely returns funds to the user. ### Successful Trade Lifecycle A trade is considered `Completed` only when it successfully passes through the following sequential stages: * `Trade Submitted` – The Solver submits initial trade data to the protocol. * `Deposit Confirmed` – The MPC verifies that the user's deposit was received on the source chain. * `PMM Selected` – A Professional Market Maker (PMM) is selected to fulfill the trade. * `Payment Transferred` – The PMM sends the target asset to the user on the destination chain. * `Payment Confirmed` – The MPC validates that the payment has been successfully completed. * `Completed` – The trade is finalized and marked as successful, triggering settlement and releasing funds to the PMM. ### Failure Detection and Handling While the protocol is designed for high success rates, failures may occur at specific stages. The MPC plays a key role in proactively detecting and resolving failures. #### 🔍 Deposit Failure Detection * After trade submission, the MPC validates deposit details. * If a mismatch or timeout occurs, the MPC can mark the trade as `Failure`. * A trade marked as `Failure` is permanently halted and cannot proceed. * After a grace period (`timeout`), the MPC finalizes the trade and triggers an automatic refund of the user’s funds. #### 🔍 Payment Failure Detection * The payment (`paymentTxId`) may be submitted by the Solver or PMM. * The MPC verifies payment accuracy and consistency. * If a problem is detected: * The trade is moved to a `WARNING` state. * The PMM is notified and may attempt to make another payment. * If successful, the trade returns to `Confirm Payment`. * If not, the `MPC` escalates the trade to `FAILURE` after the timeout period and initiates the refund process accordingly. #### 🔍 Other Failure Scenarios * For all other stages (e.g., `Select PMM`, `Make Payment`, `Warning`, `Confirm Settlement`), failure handling is only triggered after a timeout. * The MPC monitors pending trades and moves them to `Failure` if they remain stalled. * Refund handling follows the same policy based on the auto-refund setting. > **⚠️ Note: Auto-refund is mandatory. However, in rare cases, the MPC may process the refund with a delay. Users can still manually claim refunds via the DApp interface after the timeout period if the refund hasn't been issued automatically.** # Asset-chain * Ethereum: * `ETHVault`: [0xF7fedF4A250157010807E6eA60258E3B768149Ff](https://etherscan.io/address/0xF7fedF4A250157010807E6eA60258E3B768149Ff) * `WETHVault`: [0xaD3f379AaED8Eca895209Af446F2e34f07145dbC](https://etherscan.io/address/0xaD3f379AaED8Eca895209Af446F2e34f07145dbC) * `USDTVault`: [0x0712CAB9e52a37aFC6fA768b20cc9b07325314fB](https://etherscan.io/address/0x0712CAB9e52a37aFC6fA768b20cc9b07325314fB) * `WBTCVault`: [0xCd6B5F600559104Ee19320B9F9C3b2c7672cb895](https://etherscan.io/address/0xCd6B5F600559104Ee19320B9F9C3b2c7672cb895) # Depositing Funds ### EVM-Compatible Networks #### Native Coin Deposit ```solidity function deposit(address ephemeralL2Address, TradeInput calldata input, TradeDetail calldata data) external payable; ``` 🔐 Permissionless Execution * Callable by any user initiating a native coin trade. * Requires `msg.value` to match the expected deposit amount. 🔎 Trade Validation * Ensures the caller matches the expected sender in `TradeInput`. * Checks whether the `tradeId` derived from the input has already been used. * Prevents replay attacks or duplicate trade submissions. 🔁 Trade State Transition * Records the hash of `TradeDetail` for future verification and process continuity. 📢 Event Emission * Emits a `Deposited` event with metadata required for off-chain monitoring and processing. #### ERC-20 Token Deposit ```solidity function deposit(address ephemeralL2Address, TradeInput calldata input, TradeDetail calldata data) external; ``` 🔐 Permissionless Execution * Callable by any user initiating an ERC-20 token trade. 🔎 Trade Validation * Ensures the deposited token matches the configured `LOCKING_TOKEN`. * Ensures the caller matches the expected sender in `TradeInput`. * Checks whether the `tradeId` derived from the input has already been used. * Prevents replay or re-submission of the same trade. 💸 Token Transfer * Uses `safeTransferFrom` to securely transfer tokens into the Vault contract. * The caller must approve the Vault to spend tokens prior to calling. 🔁 Trade State Transition * Records the hash of `TradeDetail` for future verification and process continuity. 📢 Event Emission * Emits a `Deposited` event with metadata required for off-chain monitoring and processing. ### [Bitcoin Network](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault) Unlike EVM and Solana networks which use smart contracts, Bitcoin utilizes the **Native Bitcoin Vault**—a non-custodial escrow built with Bitcoin's native scripting. Users deposit BTC into a P2TR (Pay-to-Taproot) address controlled by a 2-of-2 multisig between the user and the Settlement Committee. Trades are settled when both parties sign, or users can reclaim funds after timelock expiry using only their own key. For technical details on vault construction, spending paths, and security model, see [Native Bitcoin Vault.](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault) ### Solana Network #### Native SOL and SPL-token deposit Unlike EVM networks, we use a single function for depositing both native SOL and SPL tokens. The distinction between them is made using arguments and the list of accounts. ```rust pub struct TradeInput { /// The sessionId, unique identifier for the trade. pub session_id: [u8; 32], /// The solver address, the address of the solver. pub solver: [u8; 20], /// The trade information, contains the information about the origin and destination of the trade. pub trade_info: TradeInfo, } pub struct TradeDetailInput { pub timeout: i64, pub mpc_pubkey: Pubkey, pub refund_pubkey: Pubkey, } pub struct DepositArgs { /// Input trade information. pub input: TradeInput, /// Detailed trade data. pub data: TradeDetailInput, /// The tradeId, unique identifier for the trade. pub trade_id: [u8; 32], } pub fn handler_deposit<'c: 'info, 'info>( ctx: Context<'_, '_, 'c, 'info, DepositAccounts<'info>>, deposit_args: DepositArgs, ) -> Result<()> ``` 🔐 Permissionless Execution * Callable by any user initiating a trade. 🔎 Trade Validation * Ensures that the `ephemeral_account` is not associated with any active trades. * Ensures signer matches the expected spender in `TradeInput` . * Ensures the asset matches the expected value in the TradeInput. For native SOL, the asset is marked as native; otherwise, it is the public key of the SPL token. * Ensures the deposited amount is at least equal to the whitelisted minimum set by the operators. * Checks whether the `tradeId` derived from the input has already been used. * Check whether the asset was whitelisted by the operators beforehand. * Prevents replay attacks or duplicate trade submissions. * Ensures the deposited vault address matches the expected vault PDA uniquely derived for the trade. 💸 Token Transfer * Use `spl_token::transfer_checked` instruction to securely transfer SPL-token with the correct accounts. * Use `system_program::transfer` instruction to transfer native SOL with the correct accounts. 🔁 Trade State Transition * Creates a `TradeDetail PDA` account to store trade information for future verification and process continuity, state of the `TradeDetail` will be `Deposited` # Claim Locked Funds ### EVM-Compatible Networks #### Permissionless Token Refund ```solidity function claim(bytes32 tradeId, TradeDetail calldata detail) external; ``` 🔐 Permissionless Execution * Callable by anyone. Funds are always transferred to the `refundAddress`, ensuring there is no risk of unauthorized access or fund diversion. * Allows third parties (e.g., bots or monitoring services) to trigger refunds on behalf of users. 🔎 Trade Validation * Can only be executed after the specified timeout (`block.timestamp > detail.timeout`) has passed. * Verifies that the provided `TradeDetail` matches the recorded hash for the given `tradeId`. * Prevents unauthorized or malicious claim attempts by enforcing input authenticity. 🛡️ Replay Protection * Deletes the stored hash for the `tradeId` before transferring funds. * Protects against replay attacks and reentrancy exploits. 💸 Fund Transfer * Transfers the locked funds to the `refundAddress` specified in the original trade. * The method of transfer depends on the Vault type (either native coin or ERC-20 token). 📢 Event Emission * Emits a `Claimed` event upon successful execution. ## [Bitcoin Network](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault) #### Permissionless Token Refund ```bitcoin // User-controlled withdrawal after timelock OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG // Multi-sig spending path (before timeout) OP_CHECKSIG OP_CHECKSIGADD OP_2 OP_NUMEQUAL ``` **🔐 Permissionless Execution** \* Callable by the user after 144 blocks (\~24 hours). Funds are always transferred to the user's specified address, ensuring no risk of unauthorized access or fund diversion. \* Allows third parties (e.g., bots or monitoring services) to trigger refunds on behalf of users after timeout expiration. **🔎 Trade Validation** * Can only be executed after the specified timeout (144 Bitcoin blocks ≈ 24 hours) has passed using `OP_CHECKSEQUENCEVERIFY`. * Script validates that the timeout condition is met before allowing fund withdrawal. * Prevents unauthorized or malicious claim attempts by enforcing Bitcoin's consensus-level timelock mechanism. **🛡️ Replay Protection** * Bitcoin's UTXO model inherently prevents replay attacks - once a UTXO is spent, it cannot be spent again. * Each vault creates a unique P2TR address with specific script conditions that can only be executed once. **💸 Fund Transfer** * Transfers the locked Bitcoin to the user's specified refund address via native Bitcoin transactions. * The method depends on which script path is executed (timelock for user claims, multisig for trade settlements). **📡 Transaction Confirmation** * Bitcoin transaction is broadcast to the network and confirmed through the standard Bitcoin mining process. * Transaction details are permanently recorded on the Bitcoin blockchain for full transparency. *** **For complete technical specifications and implementation details, refer to the** [**Bitcoin Vault Script documentation**](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault)**.** ### Solana Network #### Permissionless Token Refund ```rust pub struct ClaimArgs { /// The tradeId, unique identifier for the trade. pub trade_id: [u8; 32], } pub fn handler_claim<'c: 'info, 'info>( ctx: Context<'_, '_, 'c, 'info, Claim<'info>>, claim_args: ClaimArgs, ) -> Result<()> ``` 🔐 Permissionless Execution * Callable by anyone. Funds are always transferred to the `refund_pubkey`, ensuring there is no risk of unauthorized access or fund diversion. * Allows third parties (e.g., bots or monitoring services) to trigger refunds on behalf of users. 🔎 Trade Validation * Can only be executed after the specified timeout (Clock()::get.unix\_timestamp`> trade_detail.timeout`) has passed. * Can only be executed for the `TradeDatail` in the `Deposited` state. * Verifies that the provided `TradeDetail` matches the recorded hash for the given `tradeId`. * Prevents unauthorized or malicious claim attempts by enforcing input authenticity. 🛡️ Replay Protection * Update the status of corresponding TradeDetail account from `Deposited` to `Claimed` * Transfer the asset stored in the corresponding vault and ONLY that vault to `refund_pubkey` 💸 Fund Transfer * Transfers the locked funds to the `refund_pubkey` specified in the original trade. * The method of transfer depends on the Vault type (either native coin or SPL token). # Settle Trade Payment ### EVM-Compatible Networks #### Authorized Settlement with Fee Deduction ```solidity function settlement( bytes32 tradeId, uint256 totalFee, address toAddress, TradeDetail calldata detail, bytes calldata presign, bytes calldata mpcSignature ) external nonReentrant; ``` 🔐 Permissioned Execution * Can only be executed by authorized actors capable of producing valid `mpcSignature` and `presign`. * Ensures that settlement is authorized through off-chain coordination and validation. 🔎 Trade Validation * Callable only if `block.timestamp <= detail.timeout`. * Prevents settlement after the trade has expired. * Validates that the provided `TradeDetail` matches the recorded hash for the `tradeId`. * Guards against tampering and unauthorized settlements. 🔑 Signature Verification * Verifies a pre-signature from the ephemeral asset signer. * Confirms the settlement recipient (`toAddress`) and authorized `amount`. * Requires a valid signature from the `MPC` to authorize settlement. * Ensures consensus among off-chain nodes has been reached before finalizing the trade. 💰 Protocol Fee Handling * If `totalFee` is non-zero, the specified amount is transferred to `protocol.pFeeAddr()` before proceeding with settlement. * Guarantees protocol fee collection before fund distribution. 💸 Transfer Execution * Transfers the remaining amount (`amount - totalFee`) to the PMM’s designated receiving address (`toAddress`). 📢 Event Emission * Emits a `Settled` event containing all relevant data: tradeId, fee recipient, final recipient, total fee, and transferred amount. ### Bitcoin Network Unlike EVM and Solana networks which use smart contracts, Bitcoin utilizes the **Native Bitcoin Vault**—a non-custodial escrow built with Bitcoin's native scripting. Users deposit BTC into a P2TR (Pay-to-Taproot) address controlled by a 2-of-2 multisig between the user and the Settlement Committee. Trades are settled when both parties sign, or users can reclaim funds after timelock expiry using only their own key. For technical details on vault construction, spending paths, and security model, see [Native Bitcoin Vault.](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault) ### Solana Networks #### Authorized Settlement with Fee Deduction ```rust pub struct SettlementArgs { /// The tradeId, unique identifier for the trade pub trade_id: [u8; 32], // uint256 } pub fn handler_settlement<'c: 'info, 'info>( ctx: Context<'_, '_, 'c, 'info, SettlementAccounts<'info>>, settlement_args: SettlementArgs, ) -> Result<()> ``` 🔐 Permissioned Execution * Can only be executed by authorized actors capable of producing valid `mpcSignature` and `ephemeralSignature`. * Ensures that settlement is authorized through off-chain coordination and validation. 🔎 Trade Validation * Callable only if `Clock::get().unix_timestamp <= trade_detail.timeout`. * Can only be executed for the `TradeDatail` in the `Deposited` state. * Prevents settlement after the trade has expired. * Validates that the provided `TradeDetail` matches the recorded hash for the `tradeId`. * Guards against tampering and unauthorized settlements. 🔑 Signature Verification * Verifies a signature from the ephemeral asset signer. * Confirms the settlement recipient (`toAddress`) and authorized `amount`. * Requires a valid signature from the `MPC` to authorize settlement. * Ensures consensus among off-chain nodes has been reached before finalizing the trade. 💰 Protocol Fee Handling * If `totalFee` is non-zero, the specified amount is transferred to `protocol` account before proceeding with settlement. * Guarantees protocol fee collection before fund distribution. 💸 Transfer Execution * Transfers the remaining amount (`amount - totalFee`) to the PMM’s designated receiving address (`toAddress`). * Update the status of corresponding TradeDetail account from `Deposited` to `Settled` > **📌 Note: This function represents the final stage of a successful trade. It finalizes the transfer of funds according to MPC authorization and ensures both the PMM and protocol receive their respective payments securely.** # Optimex L2 Network * Optimex L2: * `Router`: [0x1e878cCa765a8aAFEBecCa672c767441b4859634](https://scan.optimex.xyz/address/0x1e878cCa765a8aAFEBecCa672c767441b4859634) * `BTCEVM`: [0xaD3f379AaED8Eca895209Af446F2e34f07145dbC](https://scan.optimex.xyz/address/0xaD3f379AaED8Eca895209Af446F2e34f07145dbC) * `EVMBTC`: [0x0712CAB9e52a37aFC6fA768b20cc9b07325314fB](https://scan.optimex.xyz/address/0x0712CAB9e52a37aFC6fA768b20cc9b07325314fB) * `BTCSOL`: [0xfd422923d031f8AbF479390459B29f1D3f0ea4f9](https://scan.optimex.xyz/address/0xfd422923d031f8AbF479390459B29f1D3f0ea4f9) * `SOLBTC`: [0xD1EA52b7091dD45Df69f1B766e2547e8c13Ae650](https://scan.optimex.xyz/address/0xD1EA52b7091dD45Df69f1B766e2547e8c13Ae650) # Stage: Trade Initialization The trade is initialized when a user deposits funds into the designated `Vault` on the source asset-chain network (such as Bitcoin, EVM-compatible networks, or Solana). At this point, deposit confirmation is not required. A `Solver` submits the trade via the `Router` contract while awaiting deposit confirmation. ### Trade Submission Function ```plaintext submitTrade( bytes32 tradeId, TradeData calldata tradeData, Affiliate calldata affiliateInfo, SettlementPresign[] calldata settlementPresigns, RefundPresign calldata refundPresign ) external; ``` #### Permissioned Execution * Must be initiated through the `Router` contract. * Caller must be an authorized `Solver`. #### Trade Stage Validation * **Stage & Trade ID**: Ensure the trade is in the `SUBMIT` stage with a matching tradeId derived from session-specific inputs. * **Timeout**: Verify that the trade has not expired (`scriptTimeout`). * **Whitelisting**: Both source/destination chains and tokens must be whitelisted via the `Management` contract. * **MPC Key**: Ensure `mpcAssetPubkey` is active and not expired. * **PMM Check**: All participating PMMs must be registered in the Management contract. * **Affiliate Fee**: Total affiliate fees must not exceed protocol-defined limits. #### Refund Presign * **Bitcoin**: Requires a valid `refundPresign` for MPC validation. * **EVM/Solana**: Pre-signature must be empty, and `refundAddress` must match the one in `tradeData`. #### Settlement Presigns * User-submitted signatures stored, but not verified at this stage. Verification occurs at `CONFIRM_DEPOSIT`. #### Fee Calculation * **EVM/Solana**: Protocol and affiliate fees are computed when submitted. * **Bitcoin**: Protocol fee is deferred to PMM selection. Fee details (`pFeeAmount` and `aFeeAmount`) are calculated based on the trade amount and rates. #### Trade State Transition * Trade progresses to `CONFIRM_DEPOSIT`. * Records trade details, pre-signatures, and fee amounts on-chain. #### Event Emission * Emits `TradeInfoSubmitted` event providing crucial trade details. This signals the MPC to begin subsequent processing. ### Queryable Trade Data Once submitted, the following trade information is publicly queryable: * **Get Trade Stage**: ```plaintext getCurrentStage(bytes32 tradeId) external view returns (uint256); ``` * **Get Trade Data**: ```plaintext getTradeData(bytes32 tradeId) external view returns (TradeData memory); ``` * **Get Settlement Presigns**: ```plaintext getSettlementPresigns(bytes32 tradeId) external view returns (SettlementPresign[] memory); ``` * **Get Refund Presign**: ```plaintext getRefundPresigns(bytes32 tradeId) external view returns (RefundPresign memory); ``` * **Get Affiliate Info**: ```plaintext getAffiliateInfo(bytes32 tradeId) external view returns (Affiliate memory); ``` # Stage: Confirm Deposit & Failure Handling This phase follows the submission of a trade and the user's deposit of funds into a Vault on the source asset-chain. Here, Multi-Party Computation (MPC) nodes validate the trade before it continues. The MPC's key roles include: * Verifying the deposit amount and source addresses match the trade data. * Validating pre-signatures for both settlement and refund paths. * Ensuring data and signatures are consistent and untampered. ### Scenarios **✅ Successful Deposit Match** If the MPC confirms the deposits match expectations, `confirmDeposit` is called, moving the trade to `SELECT_PMM`. **❌ Failure or Timeout** If there's a mismatch, the trade is marked `Failure`, halting progress. After `scriptTimeout`, MPC triggers a refund of the user's funds. **✅ Valid Deposit: `confirmDeposit()`** **Function**: `confirmDeposit(bytes32 tradeId, bytes memory signature, bytes[] memory depositFromList) external` **Requirements**: * Called via the `Router` contract by an authorized MPC Node. * Validates trade is at `CONFIRM_DEPOSIT` stage. * Uses EIP-712 for signature verification. * Transition trade to `SELECT_PMM` upon validation. **Event**: Emits `DepositConfirmed`, indicating progression to `SELECT_PMM`. **❌ Invalid Deposit or Error: `report()`** **Function**: `report(bytes32 tradeId, bytes calldata msgError, bytes calldata signature) external` **Requirements**: * Called via the `Router` contract by an authorized MPC Node. * Trade should not be finalized as `COMPLETED`, `FAILURE`, or `REFUNDED`. * Invalid deposits trigger halt and a `FailureReported` event. **⚠️ Key Aspects to Report Failure** * Mismatch with `amountIn`. * Invalid pre-signatures. * Tampered data in `scriptInfo`. **Event**: `FailureReported`, providing transparency on failed trades. ### Queryable Trade Data **✅ On Successful Deposit Confirmation** * **Get Trade Stage**: `getCurrentStage(bytes32 tradeId)` - Returns the stage (e.g., `SELECT_PMM`). * **Get Deposit Address List**: `getDepositAddressList(bytes32 tradeId)` - Lists addresses that deposited into the Vault. **❌ On Invalid Deposit or Timeout** * **Get Trade Stage**: `getCurrentStage(bytes32 tradeId)` - Returns the stage (e.g., `FAILURE`). * **Get Failure Details**: `getFailureInfo(bytes32 tradeId)` - Provides error metadata, including stage and failure reason. # Stage: PMM Selection & Failure Handling The `SELECT_PMM` stage follows after the `MPC` confirms the deposit. At this point, the `Solver` chooses the optimal `PMM` (Professional Market Maker) based on the user's `RFQ` constraints. If a valid `PMM` isn't matched before `scriptTimeout`, the trade is marked as `FAILURE`. #### Key Responsibilities * **PMM Selection:** Choose a `PMM` offering a valid quote based on `minAmountOut`. * **Quote Verification:** Confirm the quote is valid and linked to a pre-signed settlement. * **Proof Submission:** Submit signed data from both parties to validate the trade terms. * **Fee Policy Compliance:** Ensure fees align with the user's expectations. #### Scenarios * **Successful PMM Selection:** * The protocol validates the PMM's data, locks fees, emits a `SelectedPMM` event, and advances to `MAKE_PAYMENT`. * **No Match/Timeout:** * If no PMM is selected within `scriptTimeout`, the trade is stalled. It may be marked as `Failure`, eligible for refund, and no payment occurs. #### Function Descriptions * **`selectPMM(tradeId, info)`**: * Executable only by the authorized `Solver` through the `Router`. * Validates the stage, timeout, fees, and signatures. * **`report(tradeId, msgError, signature)`**: * Executable only by authorized `MPC Node`. * The trade transitions to `FAILURE`, enabling refunds after timeout. #### Refund and Query * Post `SELECT_PMM`, query functions track trade status: * **For Success:** Use `getCurrentStage` to confirm advancement, `getPMMSelection` for selection data. * **For Failure:** Use `getCurrentStage` to confirm failure, `getFailureInfo` for error details. # Stage: Make Payment & Failure Handling Once a PMM is chosen, the trade moves to the `MAKE_PAYMENT` stage, where the PMM must transfer payment to the user and submit a `paymentTxId`. Submissions can be made by the `Solver` or the PMM to ensure transparent tracking and auditability. Failure to make the payment before `scriptTimeout` may lead the `MPC` to mark the trade as `FAILURE`. ### Solver Responsibilities * **Initiating Payment Submission (Optional):** Assist in submission if needed. * **Monitoring PMM Activity:** Ensure payment is submitted on time. ### PMM Responsibilities * **Fulfilling the Payment:** Transfer funds via an approved method. * **Submitting `paymentTxId`:** Publicly submit a verifiable transaction ID. * **Signature Authentication:** Use cryptographic signatures for authenticity. * **Acting Within `tradeTimeout`:** Complete payments before the deadline to avoid penalties. * **Retrying After Warning:** Resubmit necessary payments to correct failed trades. ### Successful Payment Submission A valid `paymentTxId` submission within `scriptTimeout` moves the trade forward, clears previous failures, and emits a `MadePayment` event. Delays beyond the `tradeTimeout` deadline can lead to rejection by the `MPC`. ### Failure: No Payment Submitted & Timeout If no valid `paymentTxId` is submitted by `scriptTimeout`, the trade is stalled. The `MPC` may use the `report()` function to mark it as failed. ### Functions and Event Emissions #### `makePayment()` Function * **Permissioned Execution:** Can be called by the authorized `Solver` or PMM via the `Router`. * **Trade Stage Validation:** Ensures correctness of stage and clears failures on valid retries. * **Timeout & Expiry Checks:** Validates against `scriptTimeout`. * **Signature Verification:** Confirms PMM’s signature for authenticity. * **Trade State Transition:** Advances to `CONFIRM_PAYMENT` and logs submission time. * **Event Emission:** Emits a `MadePayment` event for validation. #### `report()` Function If a payment is unsuccessful before `scriptTimeout`, the `MPC` reports the failure: * **Permissioned Execution:** Executable by authorized `MPC Node` via the `Router`. * **Constraints & Behavior:** Ensures trade's validity for reporting. * **Signature Verification:** Uses EIP-712 for authenticity. * **Trade State Transition:** Stores failure details and marks trade as `FAILURE`, allowing user refunds. * **Event Emission:** Emits a `FailureReported` event for monitoring. ### Queryable Trade Data #### Successful Payment * **Get Trade Stage:** Returns current trade stage (e.g., `CONFIRM_PAYMENT`). * **Get Trade Finalization:** Provides finalization details and `paymentTxId` for audit. #### No Payment & Timeout * **Get Trade Stage:** Shows current stage (e.g., `FAILURE`). * **Get Failure Details:** Provides error metadata, including stage and reason. # Stage: Confirm Payment & Failure Handling Upon the PMM's payment via `makePayment()`, including a `paymentTxId`, the trade enters the `CONFIRM_PAYMENT` phase. The `MPC`, acting as the payment verifier, must confirm the payment meets protocol specifications, checking amounts, destination chain, and `paymentTxId` accuracy. ### Steps in This Phase * **Successful Payment**: The `MPC` calls `confirmPayment()`, transitioning the trade to `CONFIRM_SETTLEMENT`, and emits a `PaymentConfirmed` event for traceability. Once confirmed, the payment is immutable. * **Failed Payment**: If discrepancies like an incorrect amount or malformed `paymentTxId` occur, the trade moves to the `WARNING` stage. Here, the `PMM` can resubmit correct payments within the `scriptTimeout`. ### Actionable Functions * **confirmPayment()** ```solidity function confirmPayment(bytes32 tradeId, bytes calldata signature) external; ``` * **Execution**: Through the `Router` by authorized `MPC Node`. * **Verification**: Ensures the trade is in the correct stage and within `scriptTimeout`. * **State Transition**: Advances trade to `CONFIRM_SETTLEMENT`, logs confirmed `paymentTxId`, and emits `PaymentConfirmed`. * **report()** ```solidity function report(bytes32 tradeId, bytes calldata msgError, bytes calldata signature) external; ``` * **Execution**: Through the `Router` by authorized `MPC Node`. * **Verification**: Ensures trade is not yet finalized. * **State Transition**: Logs failure, moves trade to `WARNING`, and emits `FailureReported`. #### Trade Data Query * **On Success**: Access trade stages and finalization details through relevant view functions. ```solidity function getCurrentStage(bytes32 tradeId) external view returns (uint256); function getTradeFinalization(bytes32 tradeId) external view returns (TradeFinalization memory); ``` * **On Failure**: Retrieve error metadata with details for resolution. ```solidity function getCurrentStage(bytes32 tradeId) external view returns (uint256); function getFailureInfo(bytes32 tradeId) external view returns (FailureDetails memory); ``` # Stage: Confirm Settlement & Failure Handling Following a confirmed payment through `confirmPayment()`, the trade moves to the `CONFIRM_SETTLEMENT` phase. In this stage, the `MPC` is tasked with settling the trade by releasing funds to the designated PMM on the source chain. Upon executing the release transaction, the MPC calls `confirmSettlement()`, submits the `releaseTxId`, and transitions the trade to the `COMPLETED` stage. If issues arise, such as network failures, and if the user has claimed a refund, the `MPC` must call the `report()` function, marking the trade as `FAILURE` and stopping further progress. Here are the core responsibilities of the MPC at this stage: * **Release Funds**: Initiates settlement by sending funds to the PMM. * **Confirm Settlement**: Calls `confirmSettlement()`. * **Report Failures**: Uses `report()` to log a failure if necessary. **⚠️ Important**: Reporting a failure means the MPC is held accountable for compensating the PMM’s loss. ### Possible Scenarios #### ✅ Successful Settlement * MPC releases funds to the PMM. * Confirms settlement with `confirmSettlement()`, using `releaseTxId`. * Trade reaches the `COMPLETED` stage. * `SettlementConfirmed` event logs the final transaction. * Trade is final and unmodifiable. #### ❌ Settlement Failure * If incapable of settling, possibly due to a network issue, and a refund is claimed, MPC reports via `report()`. * Trade is marked `FAILURE`. * `FailureReported` event is logged for transparency. * Audit records detail the failed transaction. ### Functions #### On Successful Settlement: `confirmSettlement()` ```solidity function confirmSettlement(bytes32 tradeId, bytes calldata releaseTxId, bytes calldata signature) external; ``` * **Permissioned Execution**: Only through the `Router` contract by an authorized `MPC Node`. * **Stage Validation**: Trade must be in `CONFIRM_SETTLEMENT`. * **Signature Validation**: Ensures signer validity using EIP-712. * **State Transition**: Updates trade to `COMPLETED`, records `releaseTxId`. * **Event Emission**: Emits `SettlementConfirmed`. #### On Unexpected Incidents: `report()` ```solidity function report(bytes32 tradeId, bytes calldata msgError, bytes calldata signature) external; ``` * **Permissioned Execution**: Via `Router`, authorized `MPC Node`. * **Constraints**: Trade must not be final (not `COMPLETED`, `FAILURE`, or `REFUNDED`). * **Reasons for Failure**: * Chain-level or MPC issues. * User refund claimed. * **Signature Verification**: Uses EIP-712 for authenticity. * **State Transition**: Logs failure reason, marks trade as `FAILURE`. * **Event Emission**: Emits `FailureReported`. ### Queryable Trade Data After settlement, regardless if the trade is `COMPLETED` or `FAILURE`, public view functions are available: #### On Successful Settlement * **Get Trade Stage**: ```solidity function getCurrentStage(bytes32 tradeId) external view returns (uint256); ``` * **Get Trade Finalization**: ```solidity function getTradeFinalization(bytes32 tradeId) external view returns (TradeFinalization memory); ``` #### On Unexpected Incidents * **Get Trade Stage**: ```solidity function getCurrentStage(bytes32 tradeId) external view returns (uint256); ``` * **Get Failure Details**: ```solidity function getFailureInfo(bytes32 tradeId) external view returns (FailureDetails memory); ``` # Stage: Refund After a trade is marked as `FAILURE` and the `scriptTimeout` is expired, the final step is for the `MPC` to refund the locked funds to the user. Once the refund transaction is executed, the `MPC` finalizes the process by calling the `refund()` function, submitting the `refundTxId` to log the transaction on-chain and transition the trade to the `REFUNDED` stage. If the user has already claimed the refund through an external mechanism, the `MPC` is responsible for detecting this and submitting the related transaction ID. Key responsibilities of the MPC during this phase include: * Executing the refund transaction to return funds to the user. * Confirming the refund on-chain via `refund()`. * Detecting and reporting externally claimed refunds by submitting the related transaction ID. **⚠️ Important:** The `refund()` function finalizes a failed trade, ensuring proper refund distribution and syncing off-chain data with on-chain state. ### Possible Scenarios #### Scenario 1: Refund Execution After Failure * Trade marked as `FAILURE` and `scriptTimeout` has elapsed. * `MPC` initiates the refund transaction to return funds to the user. * Upon success, `MPC` calls `refund()`, providing `refundTxId`. * Trade advances to `REFUNDED` stage, emitting a `Refunded` event for record-keeping. #### Scenario 2: Refund Already Claimed by User * Trade in `FAILURE` stage and timed out. * User independently claims the refund. * `MPC` detects the refund and calls `refund()` with `refundTxId`. * Trade is finalized as `REFUNDED`, emitting a `Refunded` event for logging. ### Successful Refund Process * **`refund()` Function**: * Signature: `refund(bytes32 tradeId, bytes calldata refundTxId, bytes calldata signature) external;` * Permissioned execution through the `Router` contract by authorized `MPC Node`. * **Trade Stage Validation**: * Ensures trade is in `FAILURE` stage. * `scriptTimeout` must have passed. * **Signature Verification**: * Utilizes EIP-712 signing to ensure data integrity. * Confirms the signer is an MPC signer for the source chain. * **Trade State Transition**: * Updates trade stage to `REFUNDED`. * Records `refundTxId` in finalization metadata. * Removes trade from pending list. * **Event Emission**: * Emits a `Refunded` event indicating trade refund and finalization. ### Queryable Trade Data After fulfilling a refund, several public view functions are available to query related data and track trade progress, essential for frontend rendering, auditability, and off-chain monitoring. * **Get Current Stage**: * Function: `getCurrentStage(bytes32 tradeId) external view returns (uint256);` * Returns the current trade stage (e.g., `REFUNDED`). * **Get Trade Finalization**: * Function: `getTradeFinalization(bytes32 tradeId) external view returns (TradeFinalization memory);` * Provides finalization details, including `refundTxId`, for future audits. # Fee Structure When executing a swap on **Optimex**, three types of fees may apply to your transaction. These fees ensure smooth operation, security, and sustainability of the protocol while maintaining competitive pricing compared to other trading platforms. Below is a breakdown of each fee type: ### 1. Network Fee (Blockchain Transaction Fee) The **network fee** covers the cost of processing transactions on the blockchain. Each trade involves an **on-chain transaction**, which incurs a standard **network fee**. The actual fee depends on factors such as: * **Network congestion** – Higher traffic increases fees due to competition for block space. * **Transaction size** – Larger transactions require more block space and result in higher fees. 🔹 ***Optimex** does not take any portion of the network fee. It is paid directly to blockchain miners or relevant blockchain validators* ### 2. Protocol Fee Users pay a **protocol fee** when swapping tokens on **Optimex Swap**, which serves as the protocol's main revenue source. Revenue is allocated to compensate the **Validator Network** and fund **research and development**. Since **Optimex** focuses on **BTC trading**, all pairs involve BTC and an asset on a **smart contract-enabled blockchain.** The protocol fee will be collected in the non-BTC asset: * **BTC → Other Asset:** The fee is deducted from the PMM’s payment to the user. * **Other Asset → BTC:** The fee is collected via the **Optimex Vault smart contract** before final settlement from such Vault to the PMM. #### **Fee Structure** * **0.02%** for **BTC-WBTC** (or other wrapped BTC pairs). * **0.1%** for all other pairs. ### 3. Affiliate Fee If users access **Optimex** through an affiliate **interface** (e.g., a wallet, DEX aggregator, or other DeFi service integrating **Optimex**), an affiliate fee may be applicable. This fee is collected by the affiliate, independent from the protocol fee and is paid by the users. 🔹 *No affiliate fee is applied on* [*Optimex's interface*](https://app.optimex.com/)*.* ### 4. Bridging Fee (only for swaps from or to EVM-compatible chains) When swapping between **BTC and an EVM-compatible chain other than Ethereum**, a small dynamic **bridging fee** is applied by our partner, [**Across**](https://across.to/). You can find the full fee formula and details here: # Governance ### 1. Listing New Supported Tokens Unlike AMM-based DEXs, **token and trading pair listings in Optimex Swap are permissioned**, as they require support from at least one **Professional Market Maker (PMM)**. New listings must be approved through a **consensus between a PMM, a Solver, and the protocol administrator**, who records the information on **Optimex’s L2**. ### 2. Protocol Fees Users pay a **trading fee** when swapping tokens on **Optimex Swap**, which serves as the protocol's main revenue source. Revenue is allocated to compensate the **Validator Network** and fund **research and development**. Since **Optimex** focuses on **BTC trading**, all pairs involve BTC and an asset on a **smart contract-enabled blockchain**, leveraging its expressivity for **fee collection**: * **BTC → Other Asset:** The fee is deducted from the PMM’s payment to the user. * **Other Asset → BTC:** The fee is collected via the **Optimex Vault smart contract** before final settlement. #### **Fee Structure** * **0.02%** for **BTC-WBTC** (or other wrapped BTC pairs). * **0.1%** for all other pairs. # Supported Chains & Tokens **Optimex Swap** supports trading between **BTC** and the following assets on **Ethereum and EVM-compatible chains**:
TokensEthereumBaseArbitrumOptimismBSC
ETHtruetruetruetruefalse
WETHtruetruetruetruetrue
WBTCtruefalsefalsefalsefalse
USDCtruetruetruetruetrue
USDTtruefalsefalsetruetrue
# Optimex Borrow Optimex Borrow is our trust-minimized, non-custodial solution for Bitcoin-backed stablecoin loans. Users can collaterize their Bitcoin and efficiently access liquidity against their BTC holdings. Using Bitcoin-native multisigs, it ensures that all transactions are native thus allowing users to borrow USDC all while your Bitcoin stays in their control. Our non-custodial design prioritizes security, ensuring you can tap liquidity without the headaches. This non-custodial design prioritizes security, ensuring users can tap liquidity without the need for wrapped tokens or centralized custodians. Key Features: * [**Self-custody Bitcoin Collaterization**](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/native-bitcoin-vault): Supply Bitcoin into a non-custodial Bitcoin-native multisig and borrow USDC, unlocking liquidity while maintain Bitcoin exposure. * **Native & Non-custodial**: No wrapping, no bridging, no custodians. Your Bitcoin stays native and secure while you retain full, verifable control at all times. * **Trust-Minimized Settlement** — The [Decentralized Validation Network](/optimex-revolutionizing-bitcoin-finance/primary-building-blocks/decentralized-validation-network) validates all loan operations using threshold signatures, ensuring no single party can access your collateral. # User Guide Optimex Borrow allows users to borrow assets (USDC) by providing collateral (BTC). It’s designed to offer flexible access to liquidity without needing to sell your holdings. Whether you're managing short-term needs or leveraging market opportunities, Optimex Borrow empowers you to stay in control. TAKE NOTE: Borrowing carries risks, such as liquidation if your health score drops below a specific level. It’s essential to regularly monitor your position and ensure a healthy collateral ratio to prevent liquidation. In the following guide, we will walk you through the entire Optimex Borrow process. # Connect Wallet In order to use services on the [Optimex platform](https://app.optimex.xyz/), users first need to connect their Web3 wallet.
For supplying BTC on the Optimex Protocol, a Bitcoin wallet is required to be connected. It is worth noting that USDC borrowed will be on EVM thus requiring a separate EVM wallet addresses. The wallet selection pop-up will appear, prompting you to select your preferred Web3 wallet to connect to the Optimex Protocol. Before authorizing the connection, you’ll be required to tick the checkbox confirming that you’ve read and agree to the Terms of Use and Disclaimers. After agreeing, authorize the connection in your chosen Web3 wallet’s UI. # Borrow Once your wallet is connected, you can click on “Supply & Borrow” to initiate a Borrow request.
Specify your desired amount of BTC to be used as collateral. You can see how much USDC you can borrow as well as based on the following metrics: * **Borrow Rate**: The borrow interest rate, calculated using a 6-hour average to reflect real market conditions more accurately. * **Loan-to-Value (LTV)**: LTV shows your current borrowing ratio between the value of your collateral and the borrowed amount. * **Health Factor Alert LTV**: The LTV threshold at which health factor alert process starts. In this process, borrowers are given a grace period of 8 hours to lower the position LTV (by repaying part of their debts). Once the grace period expires, the position will be liquidated if LTV remains higher than the threshold. * **Liquidation LTV:** Liquidation LTV is the threshold level at which your loan is unsafe and thus liquidation will occur. * **Health Factor**: Health factor shows how safe your borrow position is. It is a dynamic safety score calculated from your LTV. A health factor above **1.0** is considered safe, below **1.0** means your position is at risk of liquidation.

Based on the metrics, you can adjust your risk appetite and specify your desired USDC amount to borrow.

Once confirmed, include your EVM address under the “Receiving Address” proceed by clicking on the Review button, which will bring you to a summary of your Borrow. # Confirm & Sign Once you have confirmed all the swap details on the Optimex platform UI, the final steps are to authenticate the swap and sign-off the transfer on your Web3 wallet.
**Authenticate & confirm your Borrow request**: Your connected wallet UI will prompt you with a signature request. This signature is to transfer the indicated amount of Bitcoin to a Bitcoin-native multisig associated with Optimex Borrow. # Manage your Borrow Position After you confirm the supply transaction, while no more action is required from you, you will be taken to the next page that shows the transaction progress. In this page, you can track the status of your supply transaction and the transaction that sends you the borrowed USDC.
You can click on “View Position” to review your current Borrow position & perform the following actions: **Borrow USDC**: Allows you to borrow more USDC based on the existing amount of collateral in your position. **Repay**: You will have to connect your EVM wallet and specify your desired amount of USDC to repay. Clicking on “Repay” will prompt you with a request which includes a Token approval request which is a common practice for decentralized platforms dealing with ERC-20 tokens. After approving, the signature request will be prompted to transfer the indicated amount of USDC to Optimex. # Unlock & Close Before unlocking, users must ensure that the entire borrowed amount (e.g., USDC) has been repaid, including interest. Only when the loan is repaid, users can safely close their position and retrieve their BTC collateral.
**Unlock:** After repaying, clicking on “Unlock” will automatically start the process whereby your collateral will be released from escrow and becomes available for unlocking back to the user's connected wallet. Once you have unlocked your collateral, the lending position is officially closed, and all associated metrics—such as health factor, LTV, and liquidation price are reset. # How It Works Optimex Borrows facilitates the issuance of Bitcoin (BTC)-backed loans. In this process, borrowers are required to secure their BTC as collateral within a Native Bitcoin Vault to acquire stablecoins, specifically USDC on the Ethereum network. The underlying architecture of Optimex Borrows supports seamless integration with established lending protocols (e.g., Morpho, Euler), thereby accessing their pre-existing stablecoin liquidity reserves. Given that the collateral is BTC secured within a Native Bitcoin Vault and the loan assets are stablecoins on the Ethereum network, any necessary liquidation must be executed cross-chain. To facilitate this process, Optimex Borrows utilizes Optimex Swap for the liquidation of the BTC collateral when required. Consequently, Optimex Borrows employs the fundamental components described previously: the Native Bitcoin Vault, the Validator Network, the Communication Layer, and the Market Makers. The initial implementation of Optimex Borrows is focused on integration with the **Morpho** protocol. For expository purposes, the subsequent subsections will provide a detailed explanation of the operational mechanism of Optimex Borrows based on this current integration. Furthermore, the expansion of this functionality to encompass other **curator-based lending protocols** on the Ethereum network, other **EVM-compatible chains**, or **Solana** is considered a **straightforward extension** and constitutes our dedicated **future work**. # Borrow & Repay ### Preliminaries on Morpho Vaults and Curators * Morpho Vaults are smart contracts that accept deposits of a single loan asset (e.g., USDC, WETH). * **Curators** (e.g., Steakhouse, Gauntlet) manage the vault's strategy, dynamically allocating funds to Morpho markets based on risk and yield potential. * Each market consists of one loan asset and one collateral asset, and the collateral asset must be ERC-20 compliant. Curators can choose which asset is used as the collateral.
### Borrow Flow **(i) Supply BTC as Collateral** A Borrower is required to supply their Bitcoin (BTC) into a dedicated Bitcoin-native Vault, designated as the Optimex Collateral Vault. This vault is implemented as a 2-of-2 multi-signature (multisig) address on the Bitcoin network. The two required signers are the Borrower and the Validation Network. If liquidation becomes necessary, it will be executed through Optimex Swap, with liquidators selected from the Market Makers already onboarded onto Optimex Swap.\ Additionally, the Borrower must provide pre-signed transactions that authorize the expenditure of the BTC within the vault by the appointed liquidators. **(ii) Mint oBTC Accounting Token** Operationally, the state of the Optimex Collateral Vault is mirrored on the Ethereum network via an accounting token called **oBTC**. This oBTC token represents the locked BTC and interfaces directly with the Morpho Market (implemented as a smart contract), serving as the collateral asset within that market. Once the Validation Network confirms the successful BTC supply on the Bitcoin network and validates the Borrower’s pre-signed signatures, they mint a corresponding amount of oBTC.\ This newly minted oBTC is then supplied to the Morpho lending market, enabling the Borrower to obtain a USDC loan. **(iii) Draw USDC Loan** After the Borrower supplies oBTC as collateral to the Morpho Market, they are authorized to draw a USDC loan.\ The borrowing capacity is strictly governed by the Loan-to-Value (LTV) ratio and other configuration parameters defined in the Morpho Market. *Remark: The oBTC tokens exist solely to facilitate Optimex’s integration with the current implementation of Morpho Markets. These tokens are **not** designed to function as wrapped or fungible representations of BTC for general use. Their usage is strictly limited to the Morpho Market smart contract.*\ *They are not circulated, transferred, held, or traded by any end users of either the Optimex or Morpho platforms.* ### Repay **Loan Repayment by the Borrower** Using the Optimex User Interface (UI), the Borrower repays the USDC loan and all accrued interest directly to the Morpho Market. After the loan obligations are fully settled, the Borrower becomes eligible to redeem the BTC collateral from the Optimex Collateral Vault on the Bitcoin network. **Collateral Redemption Procedure** This redemption process is formally effected by the Validation Network through the execution of the following two sequential actions: * Redeem the oBTC tokens from the Morpho Market and burn the redeemed tokens. * Trigger the Optimex Collateral Vault to transmit the BTC collateral back to the Borrower. # Liquidation
The liquidation process mandates the use of an Oracle to provide requisite price information. Optimex Borrows utilizes the price oracle supplied by Chainlink. The Validation Network depends on this price oracle to accurately determine when to initiate a liquidation event. The liquidation process, which fundamentally involves selling the collateralized BTC for USDC to repay any outstanding USDC debt on the Morpho Market, is executed via Optimex Swap. The following details concerning this process are noteworthy: * The Validation Network, rather than the BTC owner, serves as the initiator of the swap transaction for liquidation purposes. * Given that the Borrower is required to pre-sign the transaction for potential liquidation at the outset, it is logical to expend the entire collateral amount. * After the repayment of all outstanding debt on the Morpho Market, any resulting collateral surplus which the borrower is entitled to will be denominated in USDC. # Fee Structure When using Optimex Borrows, three types of fees may apply: ### 1. Network Fee (Blockchain Transaction Fee) * **What It Covers:** Cost for processing blockchain transactions. * **Factors Impacting the Fee:** * **Network Congestion:** Higher traffic results in increased fees due to competition for block space. * **Transaction Size:** Larger transactions need more block space, leading to higher fees. * **Who Pays It:** The borrower pays this fee directly to blockchain miners or validators. Optimex does not receive any part of this fee. ### 2. Loan Initiation Fee * **What It Covers:** Charge for processing every loan disbursement. * **Fee Calculation:** 0.1% of the borrowed amount. * **Example:** * Maximum borrowing power: 100,000 USDC * Requested drawdown: 10,000 USDC * Loan initiation fee: 0.1% of 10,000 USDC = 10 USDC * Total debt: 10,010 USDC (loan amount + fee) * Optimex retains the 10 USDC fee. Borrower receives 10,000 USDC and owes 10,010 USDC, with interest on the full amount. ### 3. Liquidation Fee * **What It Covers:** Fee when the loan becomes under-collateralized. * **Fee Calculation:** Determined by Morpho's Lending Market based on current Loan-to-Value (LTV) ratio and liquidation threshold. * **Liquidation Process:** * Entire BTC collateral is sold into USDC. * Sale proceeds are used to repay the debt and cover the liquidation fee. * Borrower receives any surplus funds in USDC, not BTC. # Integration Guide This section provides and overview on how a Web3 Wallet can integrate Optimex Swap as one of the core functions in its UI. The integration comprises of two components: * Wallet-Client which is to be implemented by the Web3 Wallet provider and run natively on the Web3 Wallet UI. * `Optimex SDK-API` that runs inside a Trusted Execution Environment (TEE) on Optimex infrastructure. The TEE ensures integrity and attested execution of `Optimex SDK-API` logic, so that no attacker can tamper with its execution and cause it to deviate from the prescribed protocol. As Optimex focuses on BTC trading, all supported trading pairs involve BTC and an asset on a smart contract-enabled blockchain (e.g., EVM or Solana blockchains). Swaps that have BTC as the base asset (i.e., User want to swap from BTC to other assets such as ETH or SOL), the swap workflow is slightly different in comparison with swaps whose base assets are on EVM or Solana chains. ### BTC as base asset In this flow, `Optimex SDK-API` first requests indicative quotes from the MMs via Solver. These quotes are indicative in a sense that MMs are not bound to execute trade at these quoted rate. Among the responding MMs, a selected few will be chosen (say 3 or 4 MMs). One of these pre-selected MMs will facilitate the swap and subsequently receive the user's BTC asset. The `Optimex SDK-API` then builds a BTCScript that implements the following logic: * Within the expiry time T: Fund held in the BTCScript can be spent using a combination of 2 standard ECDSA signatures (i.e., 2-of-2 multisig). The two signers are: * the *Settlement Committee* (denoted as MPC in the figure below) * *the `Optimex SDK-API`* * After time T: The funds can be spent unilaterally by the User (via his/her Wallet-Client) if no action has been taken. Upon completing payment to the User, the PMM is expected to post the payment information onto Optimex L2. Once the Settlement Committee (aka MPC) verifies that PMM's payment to user is valid, it will present use the `Optimex SDK-API`'s signature along with its own (threshold) signature to settle the Vault. ### EVM and Solana tokens as base asset User Deposit Vault on EVM chains and Solana are implemented using smart contract, as opposed to a restricted script under UTXO model as in the case of BTC asset. The swap starts with the user identifying a few best indicative quotes and their corresponding MMs. The `Optimex SDK-API` then provides the necessary parameters for the Wallet-Client to make a deposit transaction, sending the user's asset to the corresponding Deposit Vault. The deposit transaction contains the list of pre-selected MMs. The Vault's smart contract ensures that the user asset can only be sent to one of the pre-selected MMs that facilitates the user's swap. For more technical details, including API and code example, please refer to our repository at this [link](https://github.com/optimex-xyz/provider-api-docs). # Affiliate Fee On the **Optimex** transactions that a wallet provider builds for their users, the wallet provider can add an affiliate fee. This fee is independent from the protocol fee and is paid by the users.\ \ The affiliate fee is indicated in basis points, and will be collected by **Optimex** protocol on the wallet provider behalf.\ \ In case users trade their BTC for other asset, the affiliate fee shall be collected in the PMM payment sent to the user. Alternatively, when the user swap other tokens for BTC, the affiliate fee will be collected by the **Optimex** Vault (which is implemented using a smart contract) that holds user funds during the trade.\
# Integration Guide The Optimex PMM SDK / API enables seamless integration between Professional Market Makers and the **Optimex** solver network for cross-chain liquidity provision and settlement. The integration follows a three-phase process.

PMM - Solver API Flow

#### 1. Indicative Quote * PMM receives quote requests via `/indicative-quote` endpoint * PMM responds with indicative quote, and includes session tracking for quote consistency #### 2. Commitment * If the user is interested in trading with the PMM, Solver will send a commitment request via `/commitment-quote` to the PMM * PMM responds with committed quote #### 3. Settlement * If the PMM's committed quote is selected to settle the swap, Solver will request the PMM for the settlement signature * PMM receives settlement acknowledgment from Solver * PMM makes payment to the User on an appropriate asset chain, and submits the payment information For more technical details, including API and code example for PMM to integrate with our Solver, please refer to our repository at this [link](https://github.com/optimex-xyz/market-maker-sdk). # Audits At Optimex, security is foundational to everything we build. As a cross-chain platform enabling BTC mobility in DeFi, we take trust, integrity, and user protection seriously. ### Offside Labs We’ve partnered with Offside Labs, a leading security firm known for auditing top Solana and EVM projects like Jupiter, Jito, and others. They have completed audits of both our EVM and Solana smart contracts, helping us ensure strong security across ecosystems. You can find the audit report below: {% embed url="" %} ### Omniscia Our commitment to security was further affirmed through an audit of our core lending functionality by Omniscia. This review focused specifically on the Optimex Lending Contracts Module, which handles our custom collateral token and integration with the Morpho ecosystem. The full report is available here: #### Commitment to Security As Optimex evolves, we’re committed to maintaining this standard—continuously engaging top-tier auditors and expanding our security coverage to keep the protocol safe, trusted, and future-ready. # Optimex Referral Program ### [👋🏼 Welcome to Optimex Referral Program](#user-content-fn-1)[^1] Get rewarded for growing the future of Bitcoin DeFi with Optimex. Optimex unlocks native, cross-chain BTC swaps. No wrapping, no bridges, just fast, secure, and non-custodial trading.
### 🔗 Your Referral Link Head to the 'Referral Hub' tab at the top to grab your referral link. Share it with friends and earn rewards when they trade. ### 🎁 Revenue Share Mechanism 1. **Commission** Optimex offers a two-tier referral program to reward your contributions: * **Standard Referrers** – Earn **20% commission** on protocol fees generated through your referrals. The more you refer, the more passive income you earn. * **Partners & KOLs** – Enjoy an exclusive **30% commission** - that’s **10% more** than standard referrers! Whether you're a project builders, community leaders, or content creators, we welcome you to join as a partner. Register [**HERE**](https://docs.google.com/forms/d/e/1FAIpQLSc6ZiDfFI4wnjL0tlbsdZnJPsqN9TvHNVoNuB-KRvjJ5wcs_Q/viewform?usp=dialog) to become an Optimex Partner or KOL and boost your earnings! 2. **Tracking** You can view your total earned commission anytime in the Referral Hub. 3. **Payment** * Your commission will be paid in USDT on the Ethereum chain. The fees that Optimex collects from your referrals in **USDC, USDT, ETH, or WETH** will be converted at market price when you click claim. * To claim your commission, click "Claim" in your Referral Hub once your commission reaches at least **$50**. All claimed rewards would be distributed daily between 2:00–3:00 AM UTC. ### ❓ Q\&A
What is the protocol fee on Optimex? Optimex charges a small fee based on the trading pair and swap volume: * **0.02%** for BTC-WBTC pairs (and other wrapped BTC pairs) * **0.1%** for all other trading pairs For full details, check our fee structure [**HERE**](https://docs.optimex.xyz/optimex-defi-layer-on-bitcoin-natively/optimex-swap-how-it-work/fee-structure)
When does the Optimex Referral Program start and end? The Referral Program begins on June 11, 2025. There's no set end date — the program will continue running so you can keep earning rewards.
Who can join the Optimex Referral Program? Everyone is welcome! Each user gets a personal referral code inside their Referral Hub.
How to get 30% commission instead of 20%? If you're a project or KOL looking to collaborate, simply register [HERE](https://docs.google.com/forms/d/e/1FAIpQLSc6ZiDfFI4wnjL0tlbsdZnJPsqN9TvHNVoNuB-KRvjJ5wcs_Q/viewform?usp=dialog). Our team will reach out when there’s a fit.
### 🔗 Ready to Earn? To activate your referral earnings, visit [**https://app.optimex.com/join**](https://app.optimex.com/join), generate your unique link in the Referral Hub, and share it with your network. [^1]: # Third-Party Integrations
Across **What is Across Bridge?** Across Bridge is an capital efficient cross-chain transfer solution powered by intents for end users. Across’ intents-based framework has proven to facilitate the fastest and cheapest bridging between Ethereum L2s and Mainnet. Click [here](https://docs.across.to/) for more information on Across Bridge.\ \ **Across bridge on Optimex**\ \ Optimex has integrated Across Bridge to address market demand for multi-chain functionality. This strategic integration enables seamless bidirectional swaps between Bitcoin and multiple selected EVM-compatible networks. **Initial Integration Scope:**\ \ We are launching with support for the following networks and assets: * Base: ETH, WETH, USDC * Arbitrum: ETH, WETH, USDC * BNB Smart Chain: USDT, WETH, USDC * Optimism: ETH, WETH, USDC, USDT \ **Fee Structure:** All quotes displayed within the Optimex interface reflect final pricing inclusive of bridge fees. Optimex does not impose additional charges or collect the fees on behalf of Across; all bridge fees are collected directly to Across Bridge. For comprehensive fee documentation, refer to Across [Bridge Fee Structure](https://docs.across.to/reference/fees-in-the-system).​​​​​​​​​​​​​​​​\ \ **Important Notice:** Optimex utilizes Across Bridge's cross-chain transfer infrastructure for multi-chain functionality. Users are subject to Across Bridge's Terms of Service (), which may be amended from time to time. Please visit for the most current terms and additional information.
Morpho & BProtocol **What is Morpho?** Morpho is a decentralized lending infrastructure that enables the creation of efficient, isolated crypto lending and borrowing markets. It operates through immutable smart contracts that serve as a permissionless base layer for building lending applications. Click [here](https://docs.morpho.org/curate/) for more information on Morpho. **What is BProtocol?** BProtocol is a multi-chain backstop liquidity protocol that serves as a Vault Curator on Morpho. As a Curator, BProtocol manages vault strategy and risk by: * Selecting which Morpho lending markets the vault can access • Setting supply caps to limit exposure to each market • Defining risk parameters to protect depositor funds • Managing the overall vault investment strategy Click [here](https://docs.bprotocol.org/) for more information on BProtocol. **Integration Scope** Optimex Borrow builds on Morpho’s lending infrastructure, with BProtocol curating the market’s risk parameters and strategy. This allows us to offer BTC-backed stablecoin loans through professionally managed, capital-efficient lending infrastructure. **Important Notice:** Optimex Borrow utilizes Morpho's decentralized lending infrastructure and BProtocol's vault curation services. Users are subject to Morpho's Terms of Use , which may be amended from time to time. Please visit and for the most current terms and additional information.
NEAR Intent NEAR Intent is a blockchain protocol that streamlines complex DeFi transactions across multiple chains. Instead of manually executing multiple steps, users specify their desired outcome, and a competitive network of independent solvers determines the optimal execution path. This approach eliminates technical barriers and enables seamless cross-chain financial operations without requiring users to manage the underlying complexity. Click [here](https://docs.near-intents.org/near-intents/) for more information on NEAR Intent. **How Optimex Uses NEAR Intent** Optimex Borrow leverages NEAR Intent to manage the liquidation process when borrowers' collateral values drop below maintenance thresholds. The protocol's solver network identifies and executes the most efficient liquidation strategy to safeguard lenders and maintain system stability. **Important Notice** NEAR Intent operates as a fully independent third-party protocol. All liquidation activities—including solver selection, execution routing, and transaction settlement—are controlled exclusively by NEAR Intent's decentralized infrastructure. Optimex does not manage, influence, or have oversight of NEAR Intent's operations or decision-making processes. Optimex Borrow utilizes NEAR Intent's decentralized liquidation infrastructure. Users are subject to NEAR Intent's Terms of Service (), which may be amended from time to time. Please visit for the most current terms and additional information.
Disclaimer on use of Third-party Integration/Service For ease of communication, Optimex is referred to as "we" in this disclaimer. Any natural persons or other entities who engages in any activities on Optimex shall be considered as the user of Optimex, and is referred to as "you" in the disclaimer. We hereby remind you of the risks involved in using third-party services (referred to herein as “third-party services”). 1. Your use of any third-party services on Optimex is your personal decision and we have no control over it. 2. We are not responsible for the audit of any third-party services, nor do we make any commitments or guarantees on the validity, accuracy, correctness, reliability, quality, stability, completeness and/or timeliness of the technology and information involved in such third-party services and their associated services. 3. You are solely responsible for all outcomes arising from your choice to use the third-party services and their associated services. 4. You shall make your own judgement and evaluation as to whether any third-party services and its associated services comply with the applicable laws, regulations and relevant policy requirements of your jurisdiction. We do not provide any recommendation and opinions on this subject apart from recommending you to strictly abide by the laws and regulations of your jurisdiction. 5. Outcomes and occurrences which arise out of your use of any third-party services, including but not limited to legal issues, contract liability issues, and economic loss issues, shall be resolved between you and the relevant third-party services. We are not responsible for the resolution of any outcomes or disputes arising from your choice to use the third-party services. 6. We will not share any information with any third-party services unless under your consent. Once we receive your consent, you shall be solely responsible for all legal liabilities and disputes resulting from any third-party services access to your personal information and such labilities and disputes shall be resolved between you and the relevant third-party services. **Our provision of access to third-party services on Optimex does not amount to any kind of recommendation, endorsement, or advice to use any third-party services or its associated services.**