"We should put resources toward a proper (trustless, serverless, maximally Uniswap-like UX) ETH <> BTC decentralized exchange. It's embarrassing that we still can't easily move trustlessly between the two largest crypto ecosystems." - Vitalik Buterin March 25th, 2020

Until now, the primary avenue for trading in the crypto landscape — but also a significant source of risk —has been centralized exchanges (CEXs). Nevertheless, decentralized exchanges (DEXs) – designed to mitigate CEX risk – present new hazards when cross-chain bridges with varying degrees of security and/or wrapped tokens are involved. These suffer from high centralization, overcomplication, lack of transparency, risky and costly synthetic replication (and re-replication) of finite assets. The amount of money lost in bridge hacks in 2022 alone was ~$2.6B[2], with prominent hacks of bridges such as Wormhole, HECO/HTX, Nomad, Harmony, Multichain, and BNB Chain. These bridges are insecure and cause liquidity fragmentation across many blockchains and single-chain DEXs.

The purpose of Portal Network is to offer a decentralized and trust-minimized infrastructure that is easy to use and integrate into existing blockchains, DEXs, and wallets. It allows peer-to-peer native swaps of digital assets across a range of blockchains without wrappers, bridges, centralized exchanges, and custodial DEXs (most cross-chain DEXs are not decentralized and/or require custodial elements for cross-chain coordination). In addition, we aim to provide a simple and intuitive end-user experience, with minimal slippage, and a very high level of security and transparent network operation.

To ensure robustness, we have engineered our system to withstand privacy threats, network partitions, discontinuation of Portal (the company’s) operations, DDoS attacks, order spamming, users going offline for extended periods, fee bidding wars, lockup griefing and option freeloading problems related to atomic swaps.

Why Portal?

Portal is designed to succeed where other solutions have failed. The main innovations Portal has fostered are the following:

• Built on Bitcoin: A core of Portal’s innovations is built on many layers of Bitcoin, thus inheriting security from Bitcoin.

• Atomic Swaps: Reliance on atomic swaps is the cornerstone of the Portal Network. Despite being an older idea, no product has successfully implemented atomic swaps with ease of use, speed, and low transaction fees while maintaining atomicity. The issue with HTLC swaps can be distilled to a coordination problem. After Alice and Bob agree on a price, things happen in subsequent chains that are isolated, and Alice and Bob need to be online to process the sequence of events. To solve this, Portal built a coordination protocol that decentralizes the event flow between chains, thus allowing for the trustless execution of HTLC-based swaps with greater usability.

• Embracing Layer-2 Architecture: In the swaps protocol paper, we described in detail how atomic swaps are executed on L2s of various chains, including Bitcoin; this gives us the speed of execution that competes with a centralized exchange without compromising atomicity.

• ADMM (Automated Dynamic Market Maker): We spent a lot of time and resources on innovating on the automated market maker concept. This new protocol is a significant breakthrough and a step up from industry conventions, primarily due to the intricate nature of cross-chain transfers. It introduces a range of distinctive characteristics that fundamentally redefine the ideal liquidity provider strategy. These exceptional features bring substantial benefits regarding capital efficiency and pricing precision for our users. This pioneering AMM methodology is called Automated Dynamic Market Maker (ADMM).

• Channel Factory Implementation: Not satisfied with some liquidity management on the Lightning network, Portal has implemented a simplified version of Channel Factory (L3) on top of the Lightning network. This allows for rapid and seamless trading transactions on Lightning.

How does Portal's solution compare to other cross-chain protocols?

Many “cross-chain” marketplace solutions have emerged on the scene recently. While it is clear that there is huge market demand within the sector, none have achieved widespread adoption to the extent of Uniswap, even though the addressable market seems much bigger than ERC-20 tokens alone. Some reasons for this are summarized below:

• Obscuring technical and centralization/custodial risks under the veneer of complexity has exposed LPs (Liquidity Providers) and users to severe risks of permanent capital loss. Pseudo Decentralization is a real problem.

• None of the solutions below compare to CEXs regarding usability or liquidity.

• Most cross-chain solutions are incentivized to lock up liquidity on their chain and issue synthetic assets, working against the ecosystem effect.

• Cross-chain messaging solutions are by themselves wholly inadequate to enable true cross-chain interoperability.

We explored all relevant protocols that conduct cross-chain trading or cross-chain communication. There are 2 types of issues in the ecosystem: A) code attacks, which take advantage of vulnerabilities in code and B) attacks on the design of the network, which take advantage of game theory. A common theme among all the protocols is not just that event relays could be manipulated, but because oracles or validators control the funds locked in external chain contracts, only a high level of decentralization can provide security of the network, which is highly improbable. At Portal, we designed it with this in mind. Even in the worst case scenario, validators cannot steal funds locked in Pools. The worst they could do is censor the swap transactions, without any loss of user or LP funds.

We summarize some critical network design related issues in other protocols in the table below:

Portal Network: A Strong Federation of Peer-to-Peer Nodes

The Portal infrastructure is a sophisticated suite of technology stacks, central to which is the Portal Network. This network is a peer-to-peer (P2P) system composed of independent nodes operating PortalOS, organized as a Strong Federation. This structure ensures robustness, security, and efficiency in our decentralized ecosystem.

PortalOS: The Operating System for Decentralized Swaps

PortalOS is a specialized operating system designed to run a suite of services essential for the Portal P2P Network. It's versatile and accessible, available in various formats like Bootable Live-CD/Live-USB, Amazon Machine Image (AMI), Google Cloud Image, and Netboot for PXE booting. This flexibility allows for seamless integration across different platforms and infrastructures.

Native Chain Contracts

At the heart of the Portal ecosystem are the Native Chain Contracts, which govern swap logic and payments on chains supporting Portal network operations. These contracts facilitate user interactions through clients via the Portal Swap SDK.

Portal Swap SDK

The SDK is a comprehensive toolkit comprising libraries and tools for efficient interaction with the Portal network. It provides a streamlined interface for the Portal DEX, wallets, and crypto-asset management, enhancing user experience and operational efficiency.

Welcome

Welcome to the official developer documentation for Portal, a cutting edge cross-chain DEX secured by Bitcoin constructed over a Proof-of-Stake validator network. Within this documentation, you will discover detailed information about how Portal harnesses the power of non-custodial, Layer 2 HTLC-based atomic swaps and showcases its unique Automated Dynamic Market Maker (ADMM) design for instant cross-chain swaps. Through this documentation, Blockchain and DeFi Developers will explore how to leverage these features to create exceptionally efficient and seamless digital asset trading solutions within a fully decentralized ecosystem.

A paradigm shift for true cross-chain liquidity:

The Advent of Portal: Pioneering Trustless and Censorship-Resistant Swaps

In the rapidly evolving cryptocurrency ecosystem, the importance of truly seamless cross-chain interoperability, particularly with Bitcoin, BRC-20 and Ordinals, has become increasingly vital. At Portal, our mission is to be at the forefront of this transformation: by offering users a groundbreaking platform for trustless, and censorship-resistant swaps of crypto assets. Our approach is distinct: We facilitate native asset swaps across different blockchains directly with BTC and the Bitcoin Ecosystem, eliminating the need for wrappers, bridges, or custodians.

Portal's infrastructure is poised to revolutionize decentralized finance (DeFi) on Bitcoin, catalyzing a surge in BTC's utility and value.

Portal Network: The Gateway to Hyperbitcoinization.

The vulnerabilities of centralized exchanges have been a persistent challenge/risk in the crypto ecosystem. Portal's vision is to mitigate this risk through trustless Bitcoin interoperability with other chains, leveraging fast, efficient, Layer 2 cross-chain atomic swaps. This approach promises a secure, inexpensive, and user-centric platform for asset exchange, thus opening the Portal to Hyperbitcoinization.

Key Publications & Resources:

Goals and Vision

• Decentralization: Our unwavering commitment to decentralization is underpinned by audited open-source software and transparent network operations from inception.

• Hyperbitcoinization: We envision a world where Bitcoin's adoption is accelerated through improved cross-chain coordination and innovations on Bitcoin’s Layer 2 (L2) networks, with Portal serving as a gateway.

• Cross-Chain and Cross-Layer Capabilities: We aim to empower users with a permissionless method for swapping assets across diverse chains and networks, including Layer-1 (L1) and L2 protocols, eliminating the need for wrapped assets and mitigating liquidity fragmentation.

• Utility-Centric Product: Our protocol focuses on pricing precision and minimizing slippage, positioning itself as a leader in the swapping protocol landscape.

• Seamless Composability: Designed for easy integration with wallets, aggregators, and various L1 and L2 protocols, Portal extends Bitcoin’s reach and functionality.

• Sustainable Value Capture: Aligning the protocol's success with user demand, we ensure self-sustainability and a mutually beneficial ecosystem.

Omnichain Liquidity and Multi Chain Layer-2 AMM (MC-LAMM)

Portal introduces a novel approach in Automated Market Makers (AMMs) – to create Omnichain Liquidity: individual AMMs on Bitcoin, Ethereum and other chains coordinating to form a Multi Chain Layer-2 AMM (MC-LAMM). This innovation is a significant shift from traditional AMMs, tailored to overcome the limitations of cross-chain transfers.

Layer 2 AMM: A New Approach to Liquidity Pools

Portal's MC-LAMM operates on virtual balances, in contrast to conventional AMMs like UniswapV2, which uses current balances. This approach significantly reduces the impermanent loss risk for Liquidity Providers (LPs). By constructing liquidity pools using HTLCs and payment channels, Portal ensures atomicity of exchanges while addressing the limitations of traditional HTLC models. Portal’s development includes multi-party HTLC contracts on UTXO chains like Bitcoin and smart contract-driven agents on EVM chains like Ethereum.

Bitcoin Layer 3: Extending the Lightning Network

Recognizing the potential and infrastructure of the Lightning Network, Portal extends its functionality to enable Bitcoin-based cross-chain DEX operations. Our innovations, such as implementation of Channel Factories and others, overcome current significant limitations of the Lightning Network in relevant real world applications such as cross-chain trading.

Channel Factories: Reducing User Friction by Reducing the Cost of User Deposits and Withdrawls.

Channel Factories, a concept proposed by Christain Decker, introduce a novel intermediary layer that links the Bitcoin L1 blockchain with the payment network, forming a three-layered structure. The first layer secures funds within the Bitcoin L1 blockchain through shared ownership among a cluster of nodes. The second layer, our innovative addition, consists of multi-party micropayment channels – the "channel factories." These facilitate the rapid financing of standard two-party channels. The third layer supports routine currency transfers, with each layer employing either timelocks or penalties to ensure security and trust.

Example of channel factories

Three users pool funds into a shared on-chain 3-of-3 multisig address to establish a channel factory. Using off-chain spending from this address, they create payment channels among themselves (e.g., Alice↔Bob, Alice↔Charlie, Bob↔Charlie), ensuring on-chain security while minimizing data on the blockchain by avoiding broadcast unless necessary through cooperative actions.

The multi-party channel is a duplex channel, relying on timelocks for updates of the allocation transaction. A multi-party channel generally uses an invalidation tree to extend its lifetime.

Non-Custodial Delegation: A Solution for Cross-Chain ADMM

Addressing the challenge of custodianship in cross-chain ADMM, particularly on networks like Bitcoin, Portal introduces a non-custodial delegation model. This model uses custom lightning channels between LPs and validator hubs, implemented using a variation of Discreet Log Contracts (DLCs) on Lightning. This approach ensures that validators never assume custodianship of funds, eliminating the risk of collusion and fund theft inherent in systems like Chainflip's FROST mechanism or the Validator control of User funds and attacks seen in THORChain.

The Portal Network consists of swap clients and PortalOS nodes running to make the cross-chain ADMM a reality. A core enabler for multi-blockchain interoperability is exchanging assets held by mutually untrusting owners on different ledgers atomically. Since the Portal Network is non-custodial, assets are held on the native chains (like Ethereum and Bitcoin). However, the accounting occurs on a State Chain (Notary Chain), enabling highly customized AMMs on each chain.

The main components of the network are AMMs designed on each chain. Since EVM chains are Turing Complete, this involves developing smart contracts similar to Uniswap on these networks. On Bitcoin, Portal leverages a secure and highly decentralized AMM built using a multi-party HTLC. This eliminates some centralization in other protocols that manage shared key wallets. To facilitate swaps and ensure transactions are processed promptly and appropriately, a set of validators controls the transaction flow. These validators track balances across chains, process events, and execute instructions. They maintain the Notary layer, which tracks transactions and the flow of funds.

The Portal Network constitutes a collection of PortalOS nodes actively running and executing network-level protocols in a trustless manner. PortalOS acts as an operating system configured to run a set of services required to enable various functions in the Portal Network. In essence, PortalOS serves as a protocol that facilitates the coordination of activities across multiple blockchains. It ensures smooth communication of events between these chains, playing a crucial role in keeping the entire network operational and cohesive.

Components

PortalOS consists of several components that collectively form the Portal Network. One of the main components of PortalOS is the Notary Chain built utilizing the EVMOS. The Network consists of validators called Portal Guardians, which serve as validators. A description of various components that form the PortalOS follows.

Notary Chain

The Notary Chain serves as the core database for all activity occurring in the Portal Network protocol. This chain is designed to efficiently manage a substantial volume of cross-chain swap transactions. All protocol events are recorded and broadcast by the Notary Chain. This covers almost everything, including, but not limited to:

• Registering trading pairs

• Auctions for Validators

• Slashing management

• Tracking asset balances on liquidity pools

• Tracking contributions from LPs

• Consensus Validation

• Facilitating Native Protocol Swaps via the Automated Dynamic Market Maker

• Emission Management and Fee Collection

Peer

• Peers manage native blockchains nodes necessary for network operation.

• Acts as a proxy agent for the end-user

  • Relays a user’s orders to the Coordinator

  • Manages atomic swaps

  • Interfaces with one or more L1/L2 daemons, as needed

  • Relays updates to the web and mobile clients

The schematic below shows how 2 Peers interact with the coordinator

• A protocol designed to enable coordination between different blockchains.

• Maintains state level information and event passing between peers, clients etc.

SDK

• A library that encapsulates all the common functionality to enable implementation of Portal cross-chain swaps. The Portal Swap SDK is built to empower other wallets, exchanges with the Portal's instant swaps.

• IOSClient, AndroidClient, and WebClient will import the Client library to implement their respective functionalities.

• May operate without a Peer, though Peer would remain relevant for Liquidity Providers and power-users.

Client (App)

• A browser-based application hosted by the peer to enable the user to set up and operate the peer. This is accomplished by two separate applications:

  • The Portal Peer Setup Wizard, used to set up the peer. This process involves configuring the Portal Peer to use new or existing L1/L2 network daemons, load and unload any credentials necessary for regular operation.

  • The Portal Peer App, that may be used by the Peer operator to use the services provided by the Portal network, including:

    • Trading assets

    • Settling trades by atomically swapping the assets with the counterparty

    • Interface for Liquidity Providers for staking and management

    • Interface for Validators to participate in the Auction process and keygen ceremonies etc.

Validators are an integral part of Portal Network. By maintaining the Notary Chain state, Validators secure the network with a Proof-of-Stake Consensus. To achieve this, Validators have to stake their $XPORT tokens as collateral and perform their tasks. Some of the tasks include, handling transactions, generating fresh blocks, and engaging in the consensus mechanism. Any misconduct could result in a reduction of their staked $XPORT tokens, serving as a robust deterrent against potential attacks. (A future upgrade currently in development may allow Validators to stake Bitcoin as well.)

One important design feature in Portal’s architecture is that Validators do not control any Vaults of liquidity pools as in THORChain or Chainflip. This is ideal because no amount of validator collusion can steal LP funds. Validators merely provide block generation and transaction processing on the Notary Chain and control smart contracts on native chains like EVM. This non-custodial validator nature makes Portal Network unique and hence there is no need for a large number of Validators or to maintain a security ratio of bonded assets like other protocols such as Chainflip and THORChain or Bridge protocols do.

At any point of time, there are 2 states of Validators,

• Active: Refers to an active Validator node that has won the auction and is participating in validator functions in the current epoch

• Inactive: Refers to a Validator node that has participated in a previous epoch or have not yet participated in any epoch but has an account on the Notary Chain

Recording on Notary Chain

One of the most important functions of Validators is monitoring external blockchains & PortalOS peers for events to record them on the Notary Chain. Some of these events might include:

• Registering trading pairs to onboard LPs to new liquidity pools.

• When a user initiates a swap, swap_intent() function is called on the DEX contract account, then Validators register this on the Notary Chain by calling ADMM.register() and start a timer

• Maintain a list of active Validator Set who take ownership of contracts after each epoch

• New nodes opening accounts on the Notary Chain to bond $XPORT tokens and participate in the auction process

• Maintain a ledger of Liquidity Provider contributions (by calling ADMM.commit_liquidity() and ADMM.setLP_price()) and process withdrawal requests

The process of recording is easier than it reads because Validators do not need to monitor for events themselves. As part of their PortalOS node, Peers keep track of events in external chains and Coordinator relays the events from chains and clients to the Validator server automatically (depending on block confirmation times appropriate for each chain). Once the event is monitored, ⅔ of the Active Validator set has to witness the transaction and register it on the Notary Chain, this provides transaction metadata to all listening parties.

External Chain Management

In addition to monitoring events and recording them on the Notary Chain, Validators also perform important duties on external blockchains like Ethereum and Bitcoin or other L1/L2s, such as:

• Maintain DEX smart contracts on chains like Ethereum

• Maintain a Hub node on Lightning network, which manages channels with every LP on Lightning and acts as a Liquidity Pool on Lightning

• Changing aggregate keys for TSS during Keygen ceremony

• Authorize withdrawal of LP funds when they withdraw

• Lock or Unlock $XPORT tokens on the Notary Chain when users send or transfer from the Notary Chain

Note: Unlike other protocols Validators do not control flow of funds between blockchains because that is handled through atomic swaps that is inherent in Portal’s technology. This makes it non-custodial and trustless as there is no scope for malicious behavior from a majority of Active Validator Set.

The steps below illustrate a simple set of interactions between a trader and an LP pool and Validator set.

1. Carol has funds and wants to earn rewards by providing service to the validator network

2. Carol uses her funds to buy ERC-20 token $XPORT from Ethereum Network

3. Carol uses her $XPORT token to bid for validator slot in the Validator network auction

4. If Carol has enough funds to win the validator slot in the action, Carol gets the invitation to join the Validator network authority set

5. Carol successfully participates in the keygen, rotation ceremony and becomes a part of the Authority set

6. Carol witnesses the incoming swap intents and participates in the consensus with the Authority set

7. Carol with other validators broadcast the swap intent to ADMM and broadcast the output of swap intent with price and fees to the matched LPs

8. Once LP/LPs match with the swap intent, Carol and other validators witness atomic swap between LP/LPS and Trader

9. Rewards will be accumulated to Authority set at the end of epoch in $XPORT tokens

10. A fraction of fees accumulated from every swap will be used to buy $XPORT from the open market contractually and burn to continuously equilibrate the supply of $XPORT tokens to the demand for spot and other cross-chain markets.

For every epoch, there are going to be a limited number of Validator slots (42 in Portal Network). Any potential Validator interested in participating needs to win the slot in the Auction by participating in the bidding process. Auction process starts every epoch and continues during the entire epoch period till the end of epoch. At the end of the current epoch, all highest bidders (who staked more $XPORT tokens) will win the 42 slots. After winning, Validators need to participate in the keygen ceremony and are selected as Active Validator set for the next Epoch. The existing Validator set transfers their keys to the current Active Validator Set chosen.

Validators participating in bids commit their $XPORT tokens for the auction's entirety and are restricted from shifting their status to Inactive (no current stake). Inactive Validators lacking a current bond retain the ability to withdraw funds as usual but can switch their status to bidding during the ongoing auction.

In the context of Portal Network, liquidity provisioning plays a pivotal role in facilitating the operation of the ADMM protocol. This process involves the act of depositing assets to the liquidity pools within the Portal ecosystem. In essence, by providing liquidity, LPs are engaging in a lending mechanism where their assets are made available to the protocol for utilization in various swap operations.

Liquidity provision in the Portal ADMM closely resembles the process flow commonly seen in other protocols like Uniswap V3; only Portal enables a singular transaction between multi-blockchain assets.

Liquidity provisioning in the Portal Network varies depending on native settlement chains being used. For example, Bitcoin staking on Lightning mainly involves creating a payment channel between the LP and a Liquidity Pool. On other chains like Ethereum, staking and unstaking are driven by native smart contracts. The section below will describe in brief, the essential steps involved in providing liquidity to the Portal ADMM.

Connect Wallet

Before LPs get started, they need to interact with the LP interface that is part of PortalOS. The dApp’s “connect” button lets them connect their existing wallet with the dApp. The address used to connect to the dApp is called “Contributing Address”. For assets on EVM and account-based chains, Contributing Address will be used for any future refunds. For UTXO-based assets like Bitcoin, LPs can specify a refund address.

Add Liquidity

Liquidity Providers select the assets (or pairs of assets, depending on the liquidity pool) they wish to deposit. This automatically establishes an account on the Portal Notary Chain for the LP. This account acts as the storage for LP assets and orders, playing a vital role in linking LP contributions with their addresses.

Following this, Liquidity Providers can request a Deposit Address for each asset they intend to deposit and send funds to the respective Deposit Address. Validators will monitor these transactions, crediting the liquidity provider's account balance on the Notary Chain.

Manage Liquidity

To create orders within the ADMM, Liquidity Providers must ensure they possess a sufficiently large free balance on the Notary Chain in the associated assets. The ADMM supports two types of orders:

• Range Orders: These are akin to Uniswap v3's orders.

• Limit Orders: These are maker-only orders that require a standard swap. Filled orders are automatically closed, and swapped funds are returned to the virtual free balance.

Withdrawing Liquidity

When Liquidity Providers opt to withdraw their assets, they must specify a destination address (although the refund address is used by default) to which the withdrawal funds will be sent. The Validators are responsible for deducting gas fees, generating a transaction to deposit the requested funds into the specified address, broadcasting it on the relevant external chain, witnessing the transaction, and recording it as settled.

By following these steps, developers can actively participate in liquidity provisioning within the Portal ADMM, contributing to the liquidity pool and engaging in the efficient exchange of assets on the platform.

Traders (Takers)

Traders are also asset holders and use Swap Clients to interact with the Portal Network. They use clients to place swap orders. Traders agree to a quote and can sign transactions proving ownership of the token and payments. All trades happen to be Layer 2 Atomic Swaps between the corresponding blockchains. Validators (described below) undertake the task of routing orders and maintaining the decentralized order book. Traders specify acceptable slippage on swap_intent() function call.

Liquidity Providers ( LPs )

Entities become liquidity providers (LPs) by staking a small percentage of the asset they intend to sell. This stake is stored on the native Layer 1 (L1) blockchain and is subject to forfeiture if the LP fails to fulfill their commitment.

Liquidity providers commit assets to liquidity pools with the aim of participating in a specific swap direction for a particular pair of assets. For instance, an LP might supply ETH with the intention of selling it to acquire BTC. LPs can engage in one or more liquidity pools, which are managed by the ADMM smart contract on the Notary Chain. LPs receive notifications for each swap and can adjust their liquidity position or update it at any time, irrespective of swap activity.

Compensation for LPs is derived from the spread between the assets being swapped, determined by set_LPprice(). LPs must maintain accounts on both the buying and selling chains. Parameters such as Liquidity Asset, Receiving asset, and price range guide LPs in setting up their liquidity. The LP, or group of LPs, offering the best price with sufficient liquidity is selected for a swap.

Validators

Validators provide bonded assets and run PortalOS nodes, which empowers the Portal Network by facilitating interchain co-ordination and cross-chain asset balance tracking. A significant component of PortalOS is the Portal Notary Chain. While Portal Network is a Proof-of-Stake, it is implemented using a EVMOS, built on Cosmos, which uses CometBFT consensus to achieve fast finality (a distributed, Byzantine fault-tolerant, deterministic state machine replication engine). This also makes the network resistant to node failures and potential attacks.

Although its nodes run the same software as Ethereum networks, the Notary Chain is separate from, and completely independent of, all Ethereum networks. The ADMM smart contract, which initiates and manages swaps, executes on the Notary Chain. This contract matches counterparties and determines the parameters of each swap, e.g. prices, amounts, etc. The transactions activating this contract and its output are recorded in the blocks of the Notary Chain which result from consensus between the validators.

To become a Validator, one must win the slot in an auction process (described in detail in the Validator section below). Only auction winners are permitted to participate in the process, with one validator chosen (in a round-robin manner) to act solely as the block generator or broadcaster. Block rewards are evenly distributed among all validators, and the broadcaster is determined by being the highest bidder in the previous auction. In case of equal bids, validators take turns becoming broadcasters based on their bid amounts—a system similar to Ethereum's Proof-of-Stake mechanism.

Apart from witnessing transactions within the Portal Network, validators also manage a "Coordinator" This module actively listens for and responds to events originating from Layer 1 and Layer 2 networks, facilitating the exchange of assets. Considering the limitations of the Bitcoin Virtual Machine in executing smart contracts, the DEX server additionally provides endpoints for traders to initiate BTC sales.

Some key aspects about Validators:

• The protocol's active validator set, potentially composed of at least 21 validators (subject to adjustments from testnet simulations), collaboratively manages the Notary Chain based on their stake holdings.

• All validator slots operate on a permissionless basis, allowing any validator operator with sufficient $XPORT token to outbid others and secure a position within the validator set by winning slots through regular auctions.

• Each individual validator possesses its unique set of Private Keys, utilized to generate an aggregate Public Key per epoch and contribute to the consensus process within the Notary Chain.

• Validators create secrets at the onset of each epoch, serving specific functions such as operating a hub for multi-party channels on Bitcoin and owning Smart Contract on other chains like Ethereum.

The Validator Set's role on the Notary Chain includes:

• Attestation:

  • Maintain and update the Notary Chain through a Proof-of-Stake Consensus.

  • Achieve consensus regarding incoming deposits and record them on the blockchain..

  • Achieve consensus on the proposed transactions to be signed and broadcast.

• Settlement:

  • Engage in Threshold Signature Scheme (TSS) key generation ceremonies to take ownership of multi-party hub contracts on Bitcoin and Smart Contracts (EVM and like).

  • Participate in TSS Signing ceremonies to register and broadcast transactions between swapping parties.

Because of the functions performed, Validators are awarded $XPORT tokens every block, with the ability to receive the tokens at the end of the epoch. Each epoch is 1 month to 1 quarter. More information about $XPORT tokens can be found in the token section.

Validators are integral for maintaining a secure and reliable network, necessitating penalties to deter subversive behavior. The Active Validator set possesses shares in keys, but the authorization to move funds or call a crossway contract requires at least 28 of the maximum 42 validators to be online and able to authorize transactions. Hence, the protocol implements penalties to encourage consistent, secure performance among Validators.

While discouraging Validator downtime is essential, legitimate reasons, such as connectivity issues or software updates, should be respected. Penalizing minor offline periods could adversely affect network operations. To balance these considerations, the Portal Network employs a unified slashing and reputation system within a time-based framework, encompassing both positive and negative reputation scores. These are not unique to Portal Network and are inspired by other protocols that implement slashing and reputation management.

This system primarily applies to Active Validators, and not Inactive Validators who lack reputation, aren't rewarded when offline, and can't be slashed. Validators start with a reputation score of zero and stay at this level until joining the Active Validator Set. Three on-chain states—Online, Offline, and Suspended directly influence their Reputation score. Being Online allows for rewards and reputation accumulation, whereas Offline status decreases reputation gradually. Suspension leads to complete reputation loss. In the case of a negative reputation while offline, periodic slashing occurs until the Validator restores the Online state, with a higher negative reputation accelerating the slashing rate.

A limit exists on slashing; no more than two thirds of a Validator's staked collateral can be slashed. This safeguard provides an incentive to return online.

ADMM Swaps

Portal's Automated Market Maker (AMM) protocol introduces a new paradigm shift from the current industry conventions, primarily in handling complex cross-chain transfers. The Portal AMM brings a set of unique traits that redefine the optimal liquidity provider strategy. These distinctive features offer significant advantages in terms of capital efficiency and pricing accuracy for our users. This groundbreaking AMM approach, known as "ADMM" (Automated Dynamic Market Maker), stands out in the market, with only a few comparable trading products currently in operation. Thus, highlighting the innovative nature of Portal's ADMM methodology.

The generalized flow of a swap of two crypto-assets is depicted in the schematic above. In the case of swapping ETH/ERC-20 with BTC, ETH/ERC-20 is transacted on the Ethereum L1 and BTC is transacted on the Lightning L2. For crypto assets being transacted on L1s capable of supporting smart contracts and persistent storage (Ethereum in this case) there is a “DEX Contract” account that manages the initiation and execution of swaps and also manages compensation paid to validators and LPs.

Portal DEX implements non-custodial, atomic swap of two cryptocurrencies residing on different L1s or L2s. “Non-custodial” means that, until successful completion of a swap, custody of a trader’s assets are not transferred to any parties. “Atomic” means that, for the scenario of trader Alice swapping with trader Bob, the only possible outcomes are: (1) Alice gets Bob’s asset AND Bob gets Alice’s asset (i.e. the swap occurs); or (2) both Alice AND Bob retain their original assets (i.e. no swap occurs).

The first version of the Portal DEX implements swaps of BTC (via the Lightning L2) and ETH/ERC20 (via the Ethereum L1). The components of, and participants in, the Portal DEX are depicted in Figure above.

Traders initiate the sale of a cryptocurrency they currently own in order to buy another cryptocurrency, i.e. a “swap”. Traders do not trade directly with each other but with Liquidity Pools managed by a Dynamic Market Maker (ADMM) smart contract that executes on the Notary Chain. The Notary Chain operates in parallel with all L1s and L2s involved in swaps. The nodes of the Notary Chain are run by Validators. Liquidity Providers (LPs) commit to being counterparties to specific swaps by depositing cryptocurrencies into liquidity pools.

The operational logic of the Portal DEX is distributed across smart contracts executed on both the Notary Chain and the respective Layer 1 (L1) chains hosting the swapped assets.. Smart contracts on the Notary Chain oversee Liquidity Pools and pair LP pools for each swap. Concurrently, smart contracts or scripts on L1s implement escrow mechanisms, predominantly in the form of Hashed TimeLock Contracts (HTLCs), to govern asset transfers. HTLCs are configured with the hash of a secret generated by the trader. To obtain the counterparty's asset, the trader must disclose the secret, enabling the counterparty to retrieve the trader's asset. If either party fails to reclaim the counterparty's asset within the timelock duration, both parties gain the ability to retrieve their original assets.

ADMM Key Features

Automated Dynamic Market Maker (ADMM) controls all the trades on the Portal Network. In essence, it is a decentralized protocol responsible for overseeing trades across various blockchains without relying on any central party. Some key features of ADMM are listed below.

• ADMM's implementation is similar to Uniswap V3, offering support for market orders, range orders, and limit orders.

• Liquidity Providers (LPs) have the flexibility to establish range orders at their discretion, introducing a specified quantity of a particular asset into the corresponding liquidity pool. ADMM verifies the LP's financial capacity to meet the commitment and subsequently updates the caller's liquidity commitment in a global data structure.

• The price range, spanning from the lower to the upper bounds, is divided into increments known as ticks. The total allocated liquidity for the range order is evenly distributed across each of these ticks. Consider the following example:

• • Range Order: Consider a range order with 10,000 units of liquidity, specified for a price range between 1 and 2.

  • Conversion into Limit Orders: This range order will be transformed into multiple limit orders, each positioned at a distinct tick within the range.

  • Liquidity Allocation: Given our tick spacing of 0.0001, each tick between 1 and 2 will have an associated limit order with 1 unit of liquidity allocated to it. This ensures that the total liquidity is evenly spread across the entire price range.

• Swap transactions incur lower costs on the Notary Chain and can leverage liquidity positions for each trade, a feature that proves prohibitively expensive in Uniswap.

• Swap transactions are also grouped together to be processed per block on the Notary Chain, this mitigates the risk of swaps being front run by a participant.

ADMM Swap Flow

Trader User Flow

1. User Alice has ETH and wants to sell for BTC using the Portal Network

2. Alice creates a swap intent with the DEX CA on Ethereum by time-locking ETH and specifying the swap conditions

3. Validators register the swap intent on the coordination chain

4. LPs can provide custom concentrated positions

5. LPs and trader Alice gets matched for the HTLC swap with the quoted price from the coordination chain

6. LPs create the second leg of the HTLC by time-locking the BTC

7. Alice uses the atomic swap secret to withdraw BTC, and LP gets ETH

LP User Flow

1. LP Bob wants to earn yield from providing liquidity for PORTAL cross chain swaps

2. LP creates a multisig with validator network with time-lock till end of epoch

3. LP time-locks BTC and stakes 2% of total liquidity with validators

4. LP commits liquidity positions on the coordination chain

5. If LP backs out of a trade after matching with trader then 2% of the trade amount from the stake will be slashed

6. LP withdraws at the end of epoch or continues to the next epoch

7. LPs receive a cut of the swap fee for each trade, paid in native swapping tokens.

8. Swap fees for client: 0.3% (TBD) of Client’s token

9. LP facilitating the trade gets 50% of the fees and the DEX Contract Account (CA) receives 50% of the fees which is distributed among validators

Staking in the context of validators within a decentralized exchange (DEX) like the Portal Network serves several key purposes such as below.

Security and Trust: Staking acts as a mechanism to ensure the integrity and reliability of the validators. Validators are required to lock up a certain amount of $XPORT as a form of collateral. This staking requirement discourages malicious or negligent behavior since validators stand to lose their stake if they act against the network's rules or fail to perform their duties effectively.

Network Participation Incentives: Validators are incentivized to participate actively and honestly in the network's processes, such as validating transactions or swaps, through staking. They often receive rewards in the form of transaction fees or newly minted tokens, proportional to their stake at the end of the epoch. This incentive structure encourages Validators to remain online, act in the best interest of the network, and contribute to its overall health and efficiency.

Decentralization and Fairness: By allowing various participants to become Validators through staking, the system can promote a more decentralized model of governance. It ensures that no single entity has overarching control over the network, contributing to a fair and distributed system.

Reputation accrues for Validators while their PortalOS node remains online and they participate in consensus. Accumulating reputation solely relies on being online. A Validator returning online with a negative balance triggers immediate slashing upon subsequent offline or suspended status. This serves as a strong incentive for rectifying issues and maintaining reliability well before the reputation balance turns negative. To prevent scenarios where a long-operating Validator stays offline for extended periods without penalty, a cap on uptime is implemented.

The Portal Network verifies a Validator node's online status via periodic polling, where Validator node must routinely submit a specific (non-significant) transaction to the Notary Chain. This transaction serves as evidence of their node connectivity. Failure to submit a valid transaction before the interval deadline on-chain automatically shifts the Validator to the Offline state, leading to reputation loss. The Validator reverts to the online state upon submitting a valid transaction at the subsequent interval deadline.

Validators can face suspension under two scenarios. Firstly, a failure to participate in a Signing Ceremony, where a selected Validator might miss signing or conveying messages, triggering a ceremony timeout. This forces a redo, decided by consensus among online Validators, resulting in the suspension of non-compliant Validators. Subsequently, a new ceremony excluding these suspended nodes is attempted to proceed with the process. Secondly, the failure to broadcast involves Validators needing funded accounts in account-based chains to broadcast transactions. If a Validator fails to submit a signed transaction to the Notary Chain for broadcast, leading to a new broadcaster selection, they are suspended from their duties. In the Suspended state, Validators are excluded from signing or broadcasting, and if the state coincides with a negative reputation, slashing penalties may apply. However, they are still expected to participate in witnessing and submit regular heartbeats.

More information regarding suspension conditions and reputation scores will be detailed in the coming weeks.

The Portal SDK packages classes presenting simple yet powerful interfaces to the Portal DEX, to wallets, and for crypto-asset management in general. Portal SDK is used for interfacing with the Portal DEX to execute swaps of crypto-assets.

1. Impact on Network Security

The requirement for Validators to stake tokens provides a dual benefit: it secures the network by putting capital at risk and ensures that Validators are invested in the network's longevity. The auction-based system for Validator selection introduces a competitive and meritocratic element, ensuring that only the most committed and capable Validators secure their positions.

2. Network Fee Structure

Projecting the network's potential revenue based on current DeFi volumes reveals the immense potential for value accrual through the fee mechanism. With a conservative estimate, the annual burn rate could create a significant deflationary impact on the $XPORT token, benefiting holders and reinforcing the network's value proposition.

a. Fee Utilization

As of the date of this writing, the combined daily volume of the top 20 Decentralized Exchanges is ~$4.5B. The current average maker/taker fees at DEXes is ~0.18%. Given the efficiency of Layer 2 swaps enabled by Portal which are much less expensive than other DEXes, we can safely assume that a 0.125% fee is low enough to attract users while still generating a meaningful revenue for Validators as well as for per Epoch token burn. As a hypothetical scenario (assuming current volumes, prices and other variables), at 10% DEX volume penetration, it would roughly be equivalent to $100M of $XPORT burned within the first 12 epochs, while another $100M is expected to be distributed to the Validators in the first 12 Epochs. Combined, these advantages could make the Portal Network quickly hypercompetitive in the DeFi space, attracting more users and, consequently, more fee revenue for burning and drive the feed forward loop of better yields > more TVL> better yields, as long as the demand for trust minimized, cheap, fast spot markets exists and grows.

b. Economic Impact

The Portal Network's token burning mechanism is a pivotal feature. By using half of the swap fees to purchase and burn $XPORT tokens, the network ensures a consistent demand for the token. This process not only reduces the overall supply but also helps stabilize and potentially increase the network’s market value.

c. Strategic Implications

The interplay between market activity (swap fees) and token scarcity (burning) creates an economic environment where the token's value is intrinsically linked to the network's usage. As the network grows and swap volumes increase, the burning mechanism could significantly enhance the token's attractiveness to both Validators and Holders.

3. Validator Economics

a. Yields and Lockups

The yield dynamics for Validators are complex. Since rewards are not directly proportional to stakes, this could encourage a more diverse Validator set, preventing collusion and potential consensus failure. This system also promotes efficiency as Validators are motivated to optimize their bids and operations to maximize returns.

b. Slashing and Penalties

The slashing mechanism, while a standard in many networks, is particularly significant in the Portal Network. It ensures Validators act in the best interest of the network. Burning the slashed tokens adds to the deflationary aspect of the tokenomics, reinforcing the token's value.

One key difference between Portal’s non-custodial structure and competitors like THORChain and Chainflip is that even in the case of a Byzantine Failure, users’ and Liquidity Providers’ funds will be safe (due to the non-custodial delegation in the ADMM)

4. Long-Term Sustainability

a. Balancing Emission and Burning

Maintaining a balance between token emissions and burning is a delicate task. The network must regularly assess and potentially adjust its policies to ensure the burning rate is effective in creating a deflationary environment without compromising network security and Validator incentives.

b. Adaptability and Governance

The network's long-term success will hinge on its adaptability. Effective governance mechanisms proposed by the community and accepted by a majority of the Validator network and stakers enable timely responses to market dynamics, technological advancements, and community needs.

$XPORT, is a utility currency of the Portal Network, it is issued as an ERC-20 token. Validators are the primary utilitarians of the token and send $XPORT to their Notary Chain account by transferring funds to the Crossway Smart Contract on Ethereum chain to acquire a balance on the Notary Chain. Notary Chain accounts are used to participate in Validator auctions and other functions.

Depositing to Notary Chain via Crossway Contract

The user submits a transaction to the Ethereum chain that calls a function in the Crossway Contract (part of Ethereum chain) that passes in their PortalAccountID and the amount of $XPORT tokens being sent.

The Active Validator set monitors the Ethereum blockchain for transactions associated with the Crossway Contract. Upon confirmation of the funding transaction within the Ethereum network, the Validator Set initiates the recording process in the Notary Chain. The account specified in the contract call becomes funded on the Notary Chain with that amount of $XPORT, which can then be used to bid in auctions for Validator slots as a validator.

Unlocking ERC-20 $XPORT via Crossway Contract

The act of moving $XPORT from the Notary Chain to the Ethereum Network is referred to as unlocking. Whenever any actor on the Portal Network wishes to unlock $XPORT collateral held on the Notary Chain to the Ethereum network, this requires the approval of the Validator Set. Throughout the auction process, a bidding Validator is restricted from withdrawing any funds. Validators are prohibited from withdrawing staked $XPORT at any given point in the epoch.

Upon a node's request on the Notary Chain to unlock $XPORT tokens, the node needs to specify the desired token amount and the Ethereum destination address, the Validator set verifies and approves the redemption if the node’s available token balance is sufficient. A registered redemption transaction, containing specifics like the amount, destination address, and redemption expiry time, is then broadcasted to the Ethereum network by the Validator Set and the Notary Chain account for the node is adjusted.

Validators must run a full PortalOS node to participate in auctioning (by staking $XPORT token) and validating the network once selected. Here are the steps to downloading, installing, and running the PortalOS node:

On a download section of our website, we will have four options available:

1. An installable image for each of AWS, Azure, and GCP, e.g., an AMI in the case of AWS.

   1. These will be made available in some sequence conditioned by market demand

2. A binary image for installing on bare hardware, e.g., via PXEboot or Netboot.

Note: If the download section of our website still needs to be put up and running, we will send the requested image directly to you. These images will contain binaries for a stack consisting of NixOS, Node.js (and relevant Node packages), the PortalOS node (which runs on Node), and an HTTP server (we will initially use a Node package for this), a Bitcoin node, an Ethereum node (geth), and a Lightning node (based on LND).

When launching the image for the first time, we plan to launch a web-based configuration wizard where you will specify configuration parameters for your installation, including, among other things, the location of nodes for Bitcoin, Ethereum, and Lightning and whether any of these should be launched locally, on a particular server, or connected via a particular network. After entering this information, the stack will be configured and re-launched according to your specified configuration.

Portals AMM based DEX relies on atomic swaps between counterparties to achieve trustlessness and avoid attack vectors from validators. Much of the earlier sections discussed how the network works, in this section we will describe basics of atomicity that is integral to Portal Network security.

Atomic Swaps represent peer-to-peer trading methods employed to transfer cryptocurrencies between distinct blockchains without bridges, wrapping, or relying on trusted third parties.

An Atomic Swap protocol ensures the following:

• When all parties adhere to the protocol, the swap occurs as intended.

• If any party deviates from the protocol, no compliant participant suffers negative consequences.

• No group has economic incentives to deviate from the protocol.

Atomic Swaps make use of Hashed Time Lock Contracts (HTLCs), which are a category of smart contracts designed to facilitate a trustless exchange of digital assets. Smart contracts employ an automated process that self-executes once all predefined conditions embedded within the contract are met.

Bitcoin Atomic Swaps are possible thanks to two key components encoded in Bitcoin’s HTLCs:

Hashlock

The hashlock mechanism enables the contract to be secured with a distinct cryptographic key that can solely be created by the depositor of the cryptocurrency. This unique key serves as a guarantee that the swap is completed when the party with the key (secret, pre-image) gives their consent to the transaction.

Timelocks

The timelock mechanism can be likened to a time limit for the swap. It guarantees that the transaction is finalized within a predefined time frame, and if this condition is not met, it makes possible the depositor to reclaim funds. Timelock plays a crucial role in ensuring security of swap transactions. It mandates that both parties must execute the swap within the stipulated time window for a successful swap.

Atomic Swaps vs. Bridges & Synthetic Assets

Atomic Swaps enable peer-to-peer exchanges, allowing users to swap cryptocurrencies directly without the need for intermediaries. On the other hand, cross-chain bridges establish a link between different blockchain networks, enabling the seamless transfer of digital assets through tokenized representations.

While both cross-chain bridges and Atomic Swaps contribute to improving blockchain interoperability and facilitate the movement of cryptocurrencies across various blockchain platforms, they operate differently. Cross-chain bridges act as connectors or intermediaries that facilitate asset transfers among multiple blockchain networks.

To use cross-chain bridges, a token must be locked on its original blockchain, after which a corresponding wrapped token or synthetic asset is generated on the target chain. This wrapped token is then deposited into a liquidity pool on the target blockchain, making it accessible for trading, transfer, or redemption for the corresponding underlying asset from the source blockchain. Wrapping generally incurs the expense of two gas fees/mining fees/transaction fees; one on each chain. Unwrapping, or redemption, again incurs the same.

Note that the two blockchains are independent, internally consistent systems that do not depend on external data to maintain or alter their contract states or order of transactions i.e, there is no enforcement of the peg or redeemability at the protocol level on either chain. Usually, either a single entity or a group of entities “guarantees the trust” in the peg between the wrapped token and the original token and its redeemability. There have been several instances of wrapped token attacks and failures and there is a need for atomicity as opposed to bridges, which is why Portal chose the more difficult but correct method of cross-chain swaps.

Example of a simple atomic swap flow

Atomic, non-custodial swaps are implemented using Hashed Time-Locked Contracts (HTLCs) residing on the L1’s or L2’s supporting the respective currencies being exchanged, i.e. there is an HTLC on each participating L1/L2. HTLCs contain the hash of a secret bit string (the “secret hash”) and are unlocked either when presented with the secret that originated the hash or after a time limit has expired.

When creating a swap order, each party supplies a secret hash and the node selects one of these for constructing both HTLCs. The party whose secret is chosen is the “secret holder” and the other party is the “secret seeker”. The secret holder is responsible for activating the HTLC using their in-the-clear, i.e. un-hashed, secret. Doing so reveals the secret to the secret seeker which may then activate their HTLC.

HTLCs are also constructed with a time limit by which they must be activated. After the time limit expires, the HTLC can no longer be unlocked with a secret and each party may retrieve their original currency any time thereafter.

Simple Swap Flow

1. SecretKnower/Maker initiates the process by generating a random 32-byte secret, which is then hashed to create hashOfSecret. An order is subsequently generated using this hashOfSecret.

2. SecretSeeker/Taker enters the picture by matching the order. Following this, SecretKnower/Maker establishes a locked deposit for SecretSeeker, utilizing the same hashOfSecret.

3. SecretSeeker/Taker acknowledges the deposit and, in response, generates a counter-deposit on the opposing chain, also utilizing the hashOfSecret lock.

4. Upon detecting an incoming payment on the opposing chain, SecretKnower/Maker proceeds to claim the original payment from SecretSeeker/Taker. Simultaneously, SecretKnower/Maker reveals the secret to SecretSeeker/Taker via chain data.

5. Subsequently, SecretSeeker/Taker employs this same secret to claim the funds on the original chain.

Portal’s Notary Chain is a highly customized application specific chain built to support fast and cheap transaction recordings to enable swaps. However, the primitives on native chains and the coordinator can support multiple use cases. Some of the potential use cases are explored below:

• Non-custodial Peer-Peer Swaps

• AMMs on Cross-Chains

• Multi-chain money market aggregation - Users can stake a token as collateral on chain A and borrow an asset on chain B.

• Cross-chain composability leads to complex use cases by plugging contracts on chain A with chain B.

• Seamless swapping of gaming assets between different gaming platforms that use various blockchains.

• Inter communication between blockchains and AI related platforms to prove model provenance.

• Cross-chain Governance

• Option Contracts on Bitcoin/Lightning network

• Escrow service on Lightning network

• Off-chain smart contracts on Lightning network using Portals Bitcoin L3.

Portal Network is launching with the first 2 products described above (P2P swaps, AMM swaps) but expect developers to take advantage of the SDK in building advanced applications.

The Portal Network presents a sophisticated tokenomic design that aligns incentives for Validators, Traders, and Token holders. The combination of a decaying emission schedule with a robust burning mechanism creates a unique economic environment that could lead to substantial value accrual for the network.

Basic Overview

Portal Network follows a fixed supply with a decaying emission schedule similar to Bitcoin. The Total supply of $XPORT tokens will be 840M. The initial supply will be 276M. The initial mint at the first epoch will be 6.3% of the initial supply, and then it decays to 97% of the previous epoch every successive epoch, until the full emission target of ~840M has been reached.

Minting Schedule and Incentives

a. Minting Mechanics

Portal's emission mechanics, inspired by Bitcoin's halving model, ensures a controlled supply increase. The initial mint of 6.3% of the initial 276 million tokens at epoch 1, followed by a 3% reduction per epoch, creates a scenario where early validators are incentivized more, which draws liquidity and is expected to create a flywheel effect, while the relatively smooth reduction in minting decay over time allows for a seamless adjustment of demand to meet predicted supply and avoid sudden shocks.

b. Minting $XPORT Tokens

The minting of additional $XPORT tokens leads to an expansion of the total token supply in circulation. This incentivizes and attracts Validators, who secure the network for the block rewards. The minting formula is outlined as follows:

Minting Formula:

• Minted Tokens = 6.3% as per Protocol Rules with 3% lesser with each subsequent epoch

• This will ensure the fixed upper limit for $XPORT token

Conditions for Minting:

• Minting will be triggered by specific events such as network upgrades, rewards distribution at the end of epoch, or liquidity requirements.

• Validator Set can mint 6.3% of genesis supply * (0.97 ^ epoch number) at the end of epoch

c . Burning $XPORT Tokens

Token burning signifies the permanent elimination of a specific quantity of tokens from circulation, thereby reducing the overall token supply. This is a significant upgrade over many other tokenomics mechanisms that we know of, as of the date of this publication. The combination of a large market for spot trading across chains combined with a fixed supply, and periodic burning of tokens with fees accumulated in other tokens produces interesting properties on how being a Portal Validator is much more attractive, compared to any competing use of other tokens or yield/staking protocols. The burning process for $XPORT tokens is overseen by the Validator set at the conclusion of each epoch.

Burning Formula:

• Burned Tokens = Half of the fees accumulated from every swap will be used to buy $XPORT token from the open market and burn it, using Portal Swap mechanism.

• Token burning might also occur in various scenarios like penalty enforcement, or as part of a deflationary policy per validator governance.

Blockchains and L2s are supported.

• Bitcoin

• Lightning

• Ordinals & BRC20

• Ethereum

• Arbitrum

• Aeternity

we are working to add new chains at a rapid pace

• Disclaimer: The information contained in this documentation is preliminary and can change at any time. Furthermore, the document may contain “forward-looking statements” with uncertain risks. Also, prior to the full implementation of the Portal Network, the Portal team may publish updates to this technical paper, even substantiation updates. This documentation is, therefore, subject to correction and amendment without notice. ↑

• Coinmarketcap.com ↑

• Coingecko.com ↑