Instaswap: A Non-Custodial Cross-Chain
DEX Aggregation Protocol

1. Introduction

The cryptocurrency ecosystem has expanded to encompass hundreds of independent blockchain networks, each with its own consensus mechanism, transaction format, and native asset. A fundamental challenge facing users of this ecosystem is the fragmentation of liquidity across chains. A holder of Bitcoin who wishes to acquire Ether, Solana, or Monero must navigate a patchwork of centralized exchanges (which introduce custody risk, identity requirements, and single points of failure) or a growing but still fragmented set of cross-chain decentralized protocols (each with its own interface, supported pairs, and fee structure). This fragmentation imposes real costs on users: suboptimal execution prices due to inability to compare across liquidity sources, time spent manually querying multiple platforms, and the security risk of interacting with unfamiliar protocol interfaces.

Instaswap addresses this fragmentation by operating as a multi-protocol aggregation layer that queries 15 decentralized liquidity sources simultaneously, scores the returned routes by a composite optimization function, and presents the user with the single best execution path for their requested trade. The protocol supports three trading modes through a unified interface: instant cross-chain swaps of native assets, on-chain spot trading at market prices, and decentralized perpetual futures with leverage. Each mode shares the same non-custodial security model, in which Instaswap never takes possession of user funds at any point during the transaction lifecycle.

The term "native" is central to Instaswap's design philosophy. When a user swaps BTC for ETH through the protocol, they send real Bitcoin on the Bitcoin network and receive real Ether on the Ethereum network. No wrapped tokens, synthetic representations, or intermediary bridge contracts are involved in the core cross-chain swap path. This native-asset model is enabled by the underlying cross-chain protocols (principally THORChain, Chainflip, and Maya Protocol), which maintain their own validator networks and chain-specific liquidity vaults to facilitate trustless cross-chain settlement.

Instaswap itself is non-custodial at every stage of the transaction lifecycle. The protocol never holds user private keys, never controls user wallets, and never takes temporary custody of user funds. It functions purely as a routing, rate-optimization, and transaction-construction layer, delegating all on-chain execution to the integrated decentralized protocols. This design philosophy draws a clear architectural boundary: Instaswap is responsible for finding the best route and constructing the correct transaction; the integrated protocols are responsible for executing the swap and settling the assets on-chain.

This paper is organized as follows. Section 2 describes the protocol's history and architectural evolution. Section 3 presents the system architecture in detail, including the four-layer stack and the aggregation engine's scoring function. Section 4 examines the cross-chain swap mechanics, covering THORChain's Continuous Liquidity Pool model, Chainflip's Just-In-Time AMM, and Maya Protocol's independent cross-chain infrastructure. Section 5 details the walletless swap architecture and its privacy properties. Section 6 catalogs the supported blockchain networks and integrated liquidity protocols. Section 7 describes the transaction lifecycle. Sections 8 and 9 cover the spot and perpetual trading modules. Section 10 analyzes the fee architecture and competitive positioning. Section 11 presents the security model. Section 12 describes the developer integration surface. Section 13 covers the partner and affiliate ecosystem. Section 14 presents preliminary token economics. Section 15 discusses the product roadmap, and Section 16 concludes.

2. Protocol History and Architectural Evolution

Instaswap's development history spans from May 2018 to the present and reflects a deliberate architectural migration from centralized to fully decentralized infrastructure. Understanding this trajectory is important for contextualizing the current architecture and the design decisions that inform it.

The protocol launched in May 2018 as a licensed centralized exchange (CEX) providing fiat-to-crypto and crypto-to-crypto swap services. During this initial phase (May 2018 through January 2021), the platform established its brand, user base, and operational expertise in exchange infrastructure. The centralized architecture followed the conventional model: users deposited funds into Instaswap-controlled wallets, trades were matched internally, and users withdrew their assets after settlement. While this model provided a familiar user experience and supported fiat currency on-ramps, it carried the inherent risks of centralized custody, including the concentration of user funds in hot wallets that represent attractive targets for attackers.

Between January 2021 and July 2022, fiat-to-crypto gateways were expanded to support credit card and bank transfer purchases of major cryptocurrencies including Bitcoin, Ethereum, and several altcoins. This phase broadened the user funnel significantly by lowering the barrier to entry for users who did not yet hold cryptocurrency. The fiat gateway infrastructure required integration with payment processors, compliance with financial regulations in multiple jurisdictions, and real-time currency conversion rate management.

In May 2022, the Partners Portal was introduced, establishing the B2B integration surface that remains a core component of the current protocol. The portal provided businesses and developers with API access, embeddable swap widgets, and real-time analytics dashboards, enabling third-party platforms to offer crypto swap functionality to their own user bases without building exchange infrastructure from scratch.

The pivotal architectural transition occurred in March 2023, when Instaswap migrated to a fully decentralized, non-custodial DEX aggregation model. This transition represented a fundamental rearchitecture of the platform: the centralized order matching engine and custody infrastructure were replaced with a protocol adapter layer that routes trades through THORChain, Chainflip, and other decentralized liquidity protocols. The motivations for this transition were threefold. First, the maturation of cross-chain DEX protocols (particularly THORChain's multi-chain liquidity network) had reached a level where non-custodial cross-chain swaps were technically viable and sufficiently liquid for production use. Second, the growing frequency and severity of centralized exchange hacks and insolvencies (culminating in several high-profile collapses in 2022) validated the security thesis for non-custodial architecture. Third, user demand for privacy-preserving, accountless exchange services was increasing, particularly among holders of privacy-focused assets such as Monero.

In November 2024, walletless swap support was expanded to cover 50+ tokens including Solana and Polkadot assets. February 2025 brought integration with 10+ additional DeFi protocols and 5+ wallet providers, deepening the aggregation engine's liquidity coverage. As of March 2026, the protocol is deploying decentralized spot and perpetual trading modules, with a native utility token targeted for October 2026.

3. System Architecture

Instaswap's architecture is organized into four horizontal layers, each responsible for a distinct functional domain. User requests flow downward through the stack; execution results propagate upward. This layered design enforces a clean separation of concerns: the presentation layer handles user interaction, the aggregation layer handles routing intelligence, the protocol integration layer handles protocol-specific transaction mechanics, and the blockchain layer provides finality.

3.1. Presentation Layer

The presentation layer encompasses three client-facing interfaces. The primary web application at app.instaswap.com provides the full trading interface, including instant swap, spot trading, and perpetual trading modes. The embeddable swap widget provides a subset of this functionality (instant swaps and walletless swaps) in a single-iframe component that third-party websites can embed with a copy-paste code snippet. The public REST API provides programmatic access to quote retrieval, swap initiation, transaction status polling, and supported-asset enumeration for developers building custom integrations.

The presentation layer is responsible for user input capture, trade parameterization (asset pair selection, amount specification, destination address collection, refund address collection), quote display (including expected output amount, effective rate, selected route, estimated execution time, and fee breakdown), and transaction status reporting (pending, executing, completed, failed/refunding). The layer communicates with the aggregation layer via internal API calls and does not interact with blockchain networks directly. This separation ensures that the presentation layer can be updated, redesigned, or extended without affecting the routing logic or protocol integrations beneath it.

3.2. Aggregation Layer

The aggregation layer contains the routing engine and rate optimizer, which together constitute the core intellectual machinery of the protocol. This layer is Instaswap's primary differentiator from both centralized swap services (which route through a single internal order book or liquidity provider) and single-protocol DEX interfaces (which expose only one protocol's liquidity).

When a swap request arrives, the engine dispatches concurrent rate queries to all protocol adapters that support the requested asset pair. The concurrency is important: by querying all applicable protocols in parallel rather than sequentially, the engine minimizes the latency between the user's quote request and the displayed result, ensuring that the quotes returned are as fresh as possible relative to current market conditions.

Each returned quote is evaluated using a composite scoring function S(r) for each candidate route r, defined over four weighted factors:

The first factor, OutputAmount(r), represents the quantity of destination tokens the user will receive and is the primary factor in the composite score, carrying the highest weight. This factor directly captures the effective exchange rate inclusive of all protocol fees and price impact. The second factor, SlippageScore(r), is an inverse function of the estimated slippage at the requested trade size relative to the route's available liquidity depth. Routes with deeper liquidity and lower slippage receive higher scores. The third factor, GasCostScore(r), accounts for the gas cost on both the source and destination chains. On expensive base-layer chains such as Ethereum mainnet during congestion, gas costs can constitute a meaningful fraction of the total trade cost, particularly for smaller trades. The fourth factor, ReliabilityScore(r), incorporates the historical success rate and execution consistency of each route, penalizing routes that have exhibited higher failure or timeout rates in recent observation windows.

The route with the highest composite score is selected and presented to the user. For a cross-chain swap such as BTC-to-ETH, the engine queries THORChain, Chainflip, and Maya Protocol in parallel. For an intra-chain swap such as ETH-to-USDC on Ethereum, the engine queries 1inch, Uniswap, SushiSwap, 0x Protocol, OpenOcean, and Kyber Network. For swaps on Solana, Jupiter is queried as the primary aggregation source. This multi-source approach guarantees that Instaswap's effective rate is at least as favorable as the best individual protocol's quote, and frequently superior when the engine identifies routing optimizations that manual single-protocol queries would miss.

3.3. Protocol Integration Layer

The protocol integration layer manages direct interfaces with each external decentralized protocol through a set of dedicated adapter modules. Each adapter normalizes a protocol's external API, transaction construction format, chain-specific signing requirements, deposit address generation mechanism, and status polling endpoints into a common internal interface consumed by the aggregation layer above.

This adapter architecture follows a plugin model that decouples the aggregation engine from the specifics of any individual protocol. When a new liquidity protocol is integrated, the development effort is confined to implementing a single adapter that conforms to the internal interface contract. The aggregation engine, presentation layer, and all other adapters remain unchanged. This design enables Instaswap to expand its liquidity coverage incrementally without system-wide modifications.

Each adapter is responsible for several protocol-specific functions. Quote retrieval involves translating the internal asset-pair notation into the protocol's native format, dispatching the rate query, and normalizing the returned quote into the common internal schema. Transaction construction involves assembling the protocol-specific transaction payload, including memo fields (used by THORChain to encode swap instructions), vault addresses, gas estimation, and any required auxiliary data. Deposit address generation (for cross-chain walletless swaps) involves requesting a time-limited inbound address from the protocol's vault infrastructure. Status monitoring involves polling the protocol's transaction tracking endpoints and translating protocol-specific status codes into the internal status taxonomy (pending, confirming, executing, completed, failed, refunding).

The protocol integration layer currently maintains adapters for 15 protocols spanning three categories. Three are cross-chain DEXs: THORChain, Chainflip, and Maya Protocol. Five are DEX aggregators: 1inch, Jupiter, 0x Protocol, OpenOcean, and Kyber Network. Seven are single-chain or multi-chain DEXs: Uniswap, SushiSwap, PancakeSwap, Camelot, Pangolin, WOOFi, and Trader Joe.

3.4. Blockchain Layer

The blockchain layer represents the on-chain execution environment across 17 supported networks. Instaswap does not operate its own blockchain, consensus mechanism, or validator network. It relies entirely on the security and finality guarantees of the underlying chains and the integrated cross-chain protocols. Transactions are submitted, confirmed, and finalized according to each chain's native consensus rules, whether that is Bitcoin's proof-of-work requiring multiple block confirmations, Ethereum's proof-of-stake finality, Solana's proof-of-history slot confirmation, or any other chain-specific mechanism.

This architectural decision is deliberate. By not operating its own chain or consensus, Instaswap avoids the complexity, cost, and security responsibility of maintaining validator infrastructure. The tradeoff is that Instaswap inherits the performance characteristics (throughput, latency, finality time) of the underlying chains, but these are acceptable because cross-chain swaps are inherently bounded by the slower of the two participating chains' confirmation times.

4. Cross-Chain Swap Mechanics

4.1. The Native Asset Model

Instaswap's cross-chain swaps operate on a native-asset model in which the user sends cryptocurrency in its original form on its native blockchain and receives the destination cryptocurrency in its original form on the destination blockchain. No wrapping step, intermediary synthetic token, or bridge contract holding funds in escrow on a third-party chain is involved. This is a critical architectural distinction from the majority of cross-chain solutions in the DeFi ecosystem, which rely on lock-and-mint bridge patterns that create synthetic wrapped representations of assets on foreign chains.

In a typical bridge-based cross-chain transfer, the user deposits their native asset (say, BTC) into a bridge contract on the source chain. The bridge protocol then mints an equivalent amount of a wrapped representation (say, wBTC) on the destination chain. The user receives wBTC, which is a synthetic ERC-20 token on Ethereum that is redeemable for real BTC through the bridge's reserve. This model introduces multiple layers of risk: the bridge contract's smart contract risk, the bridge operator's custody risk over the locked native assets, the peg maintenance risk if the bridge's reserves become insolvent, and the composability risk of depending on a wrapped token that may lose its peg under stress conditions.

The historical record strongly validates the concern about bridge risk. Between 2021 and 2024, wrapped token bridges suffered a series of catastrophic exploits. The Ronin bridge was exploited for approximately $620 million. The Wormhole bridge lost approximately $320 million. The Nomad bridge was drained of approximately $190 million. The Harmony Horizon bridge lost approximately $100 million. These exploits collectively demonstrated that bridge contracts represent concentrated points of failure with extremely high loss potential. By avoiding the wrapping paradigm entirely, Instaswap's cross-chain swaps carry only the smart contract and economic security risk of the underlying cross-chain protocol (THORChain, Chainflip, or Maya), which is a fundamentally different and generally more robust security model than a bridge contract's lock-and-mint design.

4.2. THORChain: Continuous Liquidity Pools

THORChain is a purpose-built Layer 1 blockchain that operates a decentralized cross-chain liquidity network. Its consensus mechanism, based on Tendermint BFT, is secured by a set of bonded validator nodes called THORNodes. Each THORNode must bond a substantial quantity of RUNE (THORChain's native asset) as economic security collateral. The bonded RUNE is subject to slashing if a node behaves maliciously or fails to perform its duties, creating a strong economic incentive for honest operation. THORChain maintains liquidity pools and vault infrastructure on each connected blockchain, enabling it to custody and transfer native assets on foreign chains through threshold signature schemes (TSS).

The vault system is central to THORChain's cross-chain capability. On each connected chain, THORChain operates inbound vaults (which receive user deposits) and outbound vaults (which send swap outputs to users). Vault addresses are controlled by the THORNode set through threshold signature cryptography: a supermajority of validators must cooperate to produce a valid signature for any outbound transaction. No single node can unilaterally move funds from a vault. This TSS-based custody model distributes trust across the validator set rather than concentrating it in a single key holder.

When a user initiates a swap routed through THORChain, they send their source asset to THORChain's inbound vault address on the source chain, along with a memo field that encodes the swap instruction (destination asset, destination address, minimum output amount, and optional affiliate fee). THORChain's validator network observes the inbound transaction through its chain-specific observer modules, which run full or light nodes on each connected blockchain. Once the inbound transaction is confirmed according to the source chain's finality rules, the THORChain state machine processes the swap.

THORChain's pricing model is the Continuous Liquidity Pool (CLP), a variant of the constant product automated market maker formula. In a standard constant product AMM (as used by Uniswap V2), the swap output for a trade of size x against a pool with reserves X (of the input asset) and Y (of the output asset) is computed as: y = (x × Y) / (x + X). THORChain's CLP modifies this formula by incorporating a slip-based fee that is proportional to the trade's price impact on the pool. The CLP output formula is: y = (x × X × Y) / (x + X)².

The critical difference is the exponent in the denominator. By squaring (x + X), the CLP formula imposes progressively higher fees on trades that are large relative to pool depth. A small trade (where x is much smaller than X) experiences near-identical output to the standard constant product formula. A large trade (where x is a significant fraction of X) experiences materially more slippage and higher fees. This slip-based fee mechanism serves two purposes: it protects liquidity providers from adverse selection on large informed trades (because the fee compensates for the information disadvantage), and it creates a self-regulating mechanism that protects pool solvency under all market conditions by making it prohibitively expensive to drain a pool through a single large trade.

After the THORChain state machine computes the swap output, it instructs the outbound vault on the destination chain to release the corresponding output asset to the user's specified receiving address. The outbound transaction is constructed and signed through the TSS ceremony among the THORNode set, then broadcast to the destination chain's network for inclusion in a block. The user receives native assets directly in their own wallet with no intermediary tokens or additional steps required.

4.3. Chainflip: Just-In-Time AMM

Chainflip is a cross-chain DEX protocol that employs a Just-In-Time (JIT) AMM model secured by a proof-of-stake validator network. Chainflip's architecture separates concerns across two primary components: the State Chain and the chain-specific vault contracts. The State Chain is a Substrate-based blockchain that serves as the coordination layer for all cross-chain operations. It maintains the global state of all active swaps, liquidity positions, and vault balances. Validator nodes run the State Chain consensus and also operate key-share infrastructure for the multi-party computation (MPC) ceremonies that control the vault contracts on each connected chain.

Chainflip's primary technical innovation is the JIT AMM model. In traditional AMMs (including both Uniswap's constant product model and THORChain's CLP), liquidity providers deposit assets into pools at fixed price ranges and passively wait for trades to arrive. In Chainflip's JIT model, liquidity providers can observe pending swaps as they are being processed by the State Chain and update their liquidity positions in real time before the swap executes. This JIT mechanism allows liquidity providers to concentrate their capital around the actual execution price of each swap, dramatically improving capital efficiency compared to static AMMs. The concentrated liquidity reduces slippage for traders, creates a competitive market among liquidity providers who bid to provide the best execution, and reduces impermanent loss because providers can adjust their positions in response to observed order flow.

4.4. Maya Protocol

Maya Protocol extends the cross-chain DEX model with its own independent validator network, liquidity pools, and chain support. Maya operates its own consensus-secured infrastructure separate from THORChain, providing Instaswap's aggregation engine with a third independent routing option for cross-chain swaps. This independence is architecturally valuable: if THORChain or Chainflip experiences congestion, downtime, or unfavorable pool conditions for a particular pair, Maya may still offer viable execution, and vice versa. Maya's liquidity pool model is structurally similar to THORChain's CLP design, with its own native asset (CACAO) serving as the settlement medium within the protocol.

4.5. Single-Chain DEX Routing

For intra-chain swaps (swaps where both the source and destination assets reside on the same blockchain), Instaswap routes through single-chain DEXs and DEX aggregators rather than cross-chain protocols. On Ethereum, this includes 1inch, Uniswap, SushiSwap, 0x Protocol, and Kyber Network. On Solana, Jupiter serves as the primary aggregation endpoint. On BNB Chain, PancakeSwap is the primary routing destination. On Avalanche, Pangolin and Trader Joe provide native DEX liquidity. On Arbitrum, Camelot provides concentrated liquidity. WOOFi and OpenOcean operate across multiple chains and provide additional routing options. The same composite scoring function S(r) is applied to intra-chain routes.

4.6. Multi-Hop and Split Routing

In certain cases, the optimal swap path between two assets is not a single direct exchange but rather a multi-hop route that traverses one or more intermediate assets. For example, a swap from Dogecoin (DOGE) to Avalanche (AVAX) may not have a direct liquidity pool with sufficient depth on any single protocol. In this scenario, the aggregation engine can construct a multi-hop route such as DOGE to BTC (via THORChain) followed by BTC to AVAX (via THORChain or Chainflip). The two hops are processed sequentially by the cross-chain protocol's internal routing mechanism, and the user experiences the swap as a single atomic operation.

Split routing is another optimization technique available within the aggregation engine. For large trades that would incur significant price impact if routed through a single liquidity pool, the engine can split the trade across multiple pools or protocols, executing a fraction of the total volume through each route. The aggregate output from the split execution may exceed the output from a single-route execution, because each individual fraction incurs less slippage than the full amount would in a single pool.

4.7. AMM Design Comparison

Four primary AMM paradigms are represented in Instaswap's protocol set. The Constant Product Market Maker (CPMM), pioneered by Uniswap V2 and used by SushiSwap and PancakeSwap, maintains the invariant x × y = k. THORChain's Continuous Liquidity Pool (CLP) modifies the constant product formula by squaring the denominator, imposing a slip-based fee that increases with trade size. Concentrated Liquidity, introduced by Uniswap V3 and used by Camelot, allows liquidity providers to specify a price range within which their capital is active, dramatically improving capital efficiency. Chainflip's Just-In-Time (JIT) AMM represents the most dynamic approach, where providers observe incoming swap orders and concentrate their liquidity at the exact execution price in real time.

Instaswap's aggregation engine does not prefer any one AMM design a priori. Instead, it evaluates each protocol's actual quoted output for the specific trade parameters and selects the route with the best composite score.

4.8. MEV Considerations and Transaction Ordering

Maximal Extractable Value (MEV) is a significant concern in on-chain trading, referring to the profit that can be extracted by block producers or other privileged actors by reordering, inserting, or censoring transactions within a block. Instaswap's cross-chain swap architecture provides partial natural protection against sandwich attacks. For cross-chain swaps routed through THORChain or Chainflip, the swap execution occurs within the cross-chain protocol's own consensus environment, not in the public mempool of the destination chain. For intra-chain swaps on EVM networks, MEV protection depends on the specific protocol and routing path selected. Users can additionally set slippage tolerance parameters that define the minimum acceptable output, bounding the maximum loss from any price manipulation.

4.9. Confirmation Requirements and Finality

Cross-chain swap execution speed is fundamentally bounded by the confirmation requirements of the participating blockchains. Bitcoin uses probabilistic finality (industry standard 6 confirmations, approximately 60 minutes); Ethereum achieves deterministic finality after approximately 12.8 minutes; Solana achieves finality in approximately 400 milliseconds. In practice, cross-chain swaps via THORChain typically complete within 10 to 60 minutes, depending on the source and destination chains involved. Intra-chain swaps complete within a single block confirmation on the relevant chain.

5. Walletless Swap Architecture

Walletless swaps are a user-facing innovation that removes the requirement for client-side wallet connection, browser extension installation, or any software beyond a standard web browser. This mode is architecturally significant because it eliminates one of the most persistent friction points in decentralized exchange adoption.

5.1. Ephemeral Deposit Address Mechanism

The walletless swap mechanism operates through ephemeral (time-limited) deposit addresses generated by the underlying cross-chain protocol at swap initiation time. The process proceeds in four discrete stages. In Stage 1, the user selects the desired asset pair and provides a receiving address on the destination chain and a refund address on the source chain. In Stage 2, Instaswap's backend coordinates with the selected protocol to generate a unique, time-limited deposit address on the source chain. In Stage 3, the user sends their source tokens to the displayed deposit address using any wallet or transfer method. In Stage 4, the cross-chain protocol executes the swap and delivers the output tokens to the user's receiving address.

5.2. Privacy Properties

The walletless architecture has significant privacy implications. Because no wallet connection is established between the user's browser and Instaswap's interface, the protocol cannot associate the user's source wallet address with their browser session, IP address, or any other client-side identifier. No account creation is required. No email address, username, password, or any other form of identity is collected. No KYC or AML verification is performed. No persistent user state is maintained between sessions.

This privacy model makes walletless swaps particularly popular for XMR-to-BTC and XMR-to-USDC conversions. The combination of Monero's on-chain privacy features (ring signatures, stealth addresses, and confidential transactions) with Instaswap's accountless, connectionless swap interface provides a multi-layered privacy architecture for users who prioritize transaction confidentiality.

5.3. Refund Handling

If a walletless swap fails, the underlying cross-chain protocol automatically refunds the user's source assets to the refund address provided in Stage 1. This refund is executed by the protocol's validator network and does not depend on Instaswap's backend being operational.

5.4. Wallet-Connected Mode

Instaswap also supports conventional wallet-connected trading for users who prefer direct wallet integration. Supported wallets include MetaMask, Ledger hardware wallets, Coinbase Wallet, and more than ten additional providers through injected provider detection, WalletConnect protocol integration, and wallet-specific adapter modules. Both wallet-connected and walletless modes maintain the same non-custodial guarantee.

6. Supported Networks and Integrated Protocols

6.1. UTXO-Based Proof-of-Work Chains

Six of the supported networks use the Unspent Transaction Output (UTXO) model combined with proof-of-work consensus. Bitcoin (BTC) uses SHA-256 double-hash proof-of-work with a 10-minute average block time. Litecoin (LTC) uses Scrypt proof-of-work with a 2.5-minute block time. Bitcoin Cash (BCH) uses SHA-256 proof-of-work with larger block sizes. Dogecoin (DOGE) uses Scrypt proof-of-work with a 1-minute block time. Dash (DASH) uses the X11 multi-algorithm proof-of-work combined with a masternode network. Zcash (ZEC) uses the Equihash proof-of-work algorithm and supports optional shielded (zero-knowledge proof-protected) transactions.

6.2. Privacy-Focused Chains

Monero (XMR) occupies a unique position among the supported networks as a purpose-built privacy-preserving cryptocurrency. Monero uses the RandomX proof-of-work algorithm, a modified UTXO model, and three layered privacy technologies: ring signatures (which mix a transaction's inputs with decoy inputs to obscure the true sender), stealth addresses (which generate one-time receiving addresses to prevent address reuse analysis), and RingCT (Ring Confidential Transactions, which hide transaction amounts using Pedersen commitments and range proofs).

6.3. Account-Based Networks

Five supported networks use account-based transaction models. Ethereum (ETH) operates on proof-of-stake consensus. BNB Chain (BNB) uses Proof-of-Staked-Authority (PoSA) consensus. Avalanche (AVAX) uses the Snowball consensus family. TRON (TRX) uses Delegated Proof-of-Stake consensus. Solana (SOL) uses a hybrid Proof-of-History and Proof-of-Stake consensus.

6.4. Layer 2 Rollups

Two supported networks are Ethereum Layer 2 optimistic rollups. Arbitrum uses an optimistic rollup architecture with fraud proof dispute resolution. Base, developed by Coinbase, uses the same OP Stack optimistic rollup architecture. Both use ETH as their native gas token.

6.5. Independent Consensus Networks

The XRP Ledger uses a federated Byzantine agreement system. Polkadot uses a relay chain with Nominated Proof-of-Stake consensus. Cosmos uses Tendermint BFT consensus with the Inter-Blockchain Communication (IBC) protocol.

6.6. Integrated Liquidity Protocols

Instaswap's protocol integration layer aggregates liquidity from 15 decentralized protocols. Three cross-chain DEXs: THORChain, Chainflip, and Maya Protocol. Five DEX aggregators: 1inch, Jupiter, 0x Protocol, OpenOcean, and Kyber Network. Seven single-chain or multi-chain DEXs: Uniswap, SushiSwap, PancakeSwap, Camelot, Pangolin, WOOFi, and Trader Joe.

7. Transaction Lifecycle

Every trade on Instaswap follows a deterministic four-stage lifecycle that preserves the non-custodial invariant at each transition.

7.1. Stage 1: Market Selection

The user selects one of three trading modes: instant swap, spot trading, or perpetual trading. Each mode activates a distinct routing pipeline within the aggregation engine.

7.2. Stage 2: Trade Parameterization and Quoting

The user specifies the source and destination assets, trade amount, destination address, and refund address. The aggregation engine dispatches concurrent rate queries, applies the composite scoring function S(r), and presents the best route including expected output, effective rate, selected protocol, estimated execution time, fee breakdown, and quote validity window.

7.3. Stage 3: On-Chain Execution

Upon user confirmation, the protocol adapter constructs the appropriate transaction. During execution, the adapter continuously polls status endpoints and reports progress through the presentation layer.

7.4. Stage 4: Settlement and Refund

Upon successful completion, swapped tokens are delivered to the user's wallet. If a swap fails, the underlying protocol's refund mechanism automatically returns source assets to the refund address, independently of Instaswap's infrastructure.

8. Spot Trading Module

Instaswap's spot trading module enables users to buy and sell crypto assets at current market prices through decentralized on-chain liquidity. The module routes market orders through the same aggregated pool of liquidity protocols, applying the composite scoring function. Unlike centralized exchanges, all pricing is derived from on-chain AMM liquidity pools with no hidden spreads. The current implementation supports market orders; limit orders, stop-loss orders, and take-profit orders are planned for future releases.

9. Perpetual Futures Module

9.1. Funding Rate Mechanism

The funding rate is a periodic payment exchanged between long and short position holders that anchors the perpetual contract's mark price to the underlying spot price. When the mark price exceeds spot, long holders pay short holders; when below spot, short holders pay long holders.

9.2. Leverage and Margin

Perpetual contracts allow traders to open positions with leverage, depositing a fraction of the position's notional value as margin collateral. Each position has initial margin and maintenance margin thresholds. If unrealized losses reduce margin below maintenance, the position is subject to liquidation. Instaswap integrates protocols where all margin collateral is held by the protocol's smart contracts, not by Instaswap.

9.3. Risk Disclosure

Perpetual trading with leverage carries substantial financial risk and is intended exclusively for experienced participants who understand derivative mechanics. Liquidation can result in total loss of deposited margin collateral. Users should carefully evaluate their risk tolerance and position sizing before engaging in leveraged perpetual trading.

10. Fee Architecture

10.1. Fee Structure

Instaswap does not charge a flat platform fee. Fees are embedded in the swap execution through the underlying liquidity protocol and reflected in the output amount presented during the quoting stage. The observed range is approximately 0.3% to 1.0%, varying by the protocol selected, the asset pair, the trade size, and current market conditions. The aggregation engine's scoring function naturally optimizes for the lowest effective fee.

10.2. Network Gas Fees

Network gas fees are separate from protocol swap fees and are determined by each chain's current congestion level. For small-denomination swaps on expensive chains, gas fees can constitute a substantial fraction of the total trade cost. The aggregation engine's GasCostScore factor accounts for this.

10.3. Competitive Positioning

ChangeNow charges approximately 0.5% to 2.0% with custodial execution. FixedFloat charges 0.5% for fixed-rate swaps and 1.0% for floating-rate swaps, also with custodial execution. Neither aggregates across multiple DEX protocols. Instaswap's advantages are the non-custodial architecture and multi-protocol aggregation across 15 decentralized liquidity sources.

11. Security Model

11.1. Non-Custodial Invariant

The foundational security property is the non-custodial invariant: at no point does the protocol take custody of user funds, hold private keys, or control user wallet addresses. An attacker who compromises Instaswap's backend infrastructure gains access to routing logic and interface code, but not to user funds.

11.2. Transport Layer Security

All communications are encrypted using TLS 1.2 or higher, providing confidentiality, integrity, and authentication.

11.3. Protocol-Level Security Inheritance

Because Instaswap delegates all on-chain execution to integrated protocols and does not deploy its own smart contracts for swap execution, the on-chain security is determined entirely by the security of the selected routing protocol. Instaswap does not introduce additional smart contract risk.

11.4. Automatic Refund Mechanism

When a swap cannot complete, the underlying protocol's validator network autonomously initiates a refund. This logic operates independently of Instaswap's backend.

11.5. Threat Model Analysis

Five primary threat categories are considered: backend compromise (limited to routing and interface manipulation, not fund access), cross-chain protocol risk (mitigated by multi-protocol integration), DNS or certificate hijacking (mitigated by DNSSEC and certificate transparency), front-end supply chain attacks (mitigated by dependency auditing and SRI hashes), and blockchain-level attacks (mitigated by confirmation requirements).

11.6. Transaction Monitoring

A public transaction explorer at explorer.instaswap.com allows users to monitor swap activity. Every swap is publicly visible on the relevant blockchains and can be independently verified.

12. Developer Integration Surface

12.1. REST API

The API provides RESTful endpoints for quote retrieval, swap initiation, status polling, and asset enumeration. It uses the CHAIN.ASSET notation for asset identification. Full documentation is published at instaswap.com/api-integration.

12.2. Embeddable Swap Widget

The widget provides a plug-and-play swap interface embeddable via a single iframe element. Widget operators earn commission on swaps executed through their embedded instance.

13. Partner and Affiliate Ecosystem

13.1. Affiliate Program

The program defines three tiers based on monthly referral volume: Starter (up to $10,000, 30% commission), Growth ($10,000 to $50,000, 40%), and Pro (above $50,000, 50%).

13.2. Partners Portal

The Partners Portal at partners.instaswap.com provides real-time analytics, integration management, 24/7 support, and co-marketing access to Instaswap's community of over 25,000 active users.

14. Tokenomics (Preliminary)

The Instaswap token has not yet launched. All parameters described in this section are preliminary and subject to revision prior to the Token Generation Event (TGE), currently targeted for October 2026. Final specifications will be published separately.

14.1. Design Intent

The token is designed to function as the utility backbone of the Instaswap ecosystem, creating economic alignment between the protocol and its user community.

14.2. Utility Vectors

Four primary utility vectors are planned: fee discounts for holders and stakers, trading cashback proportional to swap volume, tiered benefits (Bronze, Silver, Gold, Platinum, Diamond) with escalating rewards, and governance participation (structure to be determined).

14.3. Burn Mechanism

A portion of platform fee revenue will be allocated to a buy-back-and-burn program. The protocol will periodically purchase tokens on the open market and send them to a verifiable burn address, permanently removing them from circulating supply. This mechanism creates deflationary pressure that scales with platform volume. Specific parameters are not yet finalized.

14.4. Preliminary Supply Allocation

The planned distribution allocates 30% to ecosystem and rewards, 20% to team and advisors (subject to multi-year vesting), 15% to private sale participants, 15% to liquidity and market making, 10% to treasury and operational reserve, and 10% to the public sale at TGE. Vesting terms will be published before any token sale.

15. Product Roadmap

Completed phases include the initial CEX launch (May 2018 through January 2021), fiat-to-crypto gateway expansion (January 2021 through July 2022), Partners Portal launch (May 2022), the architectural pivot to multi-blockchain DEX aggregator (March 2023 through present), walletless swap expansion covering 50+ tokens (November 2024), and integration of 10+ additional DeFi protocols and 5+ wallet providers (February 2025).

The current development phase (March 2026) focuses on deploying decentralized perpetual and spot trading markets. The next major milestone is the Instaswap Token Launch, targeted for October 2026. Ongoing efforts include expanding blockchain support, deepening protocol integrations, adding advanced order types, and continuously refining the aggregation engine's scoring function.

16. Conclusion

Instaswap provides a unified non-custodial interface for cross-chain cryptocurrency swaps, spot trading, and perpetual futures by aggregating liquidity from 15 decentralized protocols across 17 blockchain networks. The protocol's aggregation engine surfaces optimal routing across fragmented liquidity sources using a composite scoring function that weighs output amount, slippage, gas cost, and route reliability. Its walletless swap mode eliminates the friction of wallet connection through an ephemeral deposit address mechanism. Its non-custodial architecture removes counterparty risk from the trade lifecycle by delegating all on-chain execution to audited third-party protocols.

The native-asset model, in which users exchange real BTC, ETH, XMR, SOL, and other tokens in their original form without wrapping or bridging, eliminates the smart contract risk of intermediary bridge contracts. This design choice is validated by the historical record of bridge exploits that have resulted in billions of dollars in aggregate losses. By delegating cross-chain execution to purpose-built protocols such as THORChain (Continuous Liquidity Pools with slip-based fees) and Chainflip (Just-In-Time AMM with real-time liquidity adjustment), Instaswap inherits robust economic security models without deploying its own custodial smart contracts.

The protocol's four-layer architecture (presentation, aggregation, protocol integration, blockchain) enforces a clean separation of concerns that enables independent evolution of each layer. The planned deployment of a native utility token in October 2026 will introduce fee discounts, volume-based cashback, tiered holder benefits, and deflationary burn mechanics designed to create economic alignment between the protocol and its user community.