PoolSwap – Multi-Chain Decentralized Crypto Exchange
What is the PoolSWAP Exchange?
It's a DEX AMM running on the Openchain Network. It is built by the same team that has built the Openchain blockchain. You could call it the "official" DEX. There can be any number of DEX-es built on Openchain, but the team wanted to build the first one because it is special.
What's special about the PoolSWAP Exchange?
Well, a number of things:
Low transaction fees: PoolSWAP runs on the Openchain blockchain platform with improved architecture, mining algorithms, and consensus, creating the premise and basis for reducing transaction fees for investors, for application developers used on the Openchain blockchain platform.
Supports many gateways: PoolSWAP has now integrated 4 crypto-transfer gateways with 04 popular blockchain networks, namely Ethereum, BNB Chain, Polygon, and Avalanche (AVAX). Coins, tokens from these 04 networks to the Openchain chain, and vice versa.
In-network SWAP: Investors can easily swap coin pairs, and tokens listed on PoolSWAP quickly, and conveniently, at a low cost.
Provide liquidity and Earn: Investors will Earn LP tokens with a preferential interest rate when providing liquidity to the exchange.
Staking/Farming to Earn: Investors can Staking their assets to get interested in term deposits at very attractive rates.
Initial DEX Offering: is a tool to help project owners Defi, dApp, Gamefi, etc. to access and mobilize capital flows automatically, transparently, and securely from investment funds and investment communities around the world through the form of issuing tokens on Openchain, registering for listing on PoolSwap, opening token sales.
NFT marketplace: This feature is still under development, providing a marketplace for investors to exchange, buy and sell all NFTs issued on Openchain and other famous blockchain networks.
Airdrop: PoolSWAP always has great Airdrop campaigns, helping to develop new communities quickly and stably.
Bug Bounty: PoolSWAP opens sustainable, behind-the-scenes reward programs for developers who detect vulnerabilities or contribute to the development of new features and architectures for the ecosystem.
Why is the PoolSWAP Exchange important?
Openchain blockchain platform has more than 100k users owning wallets, with transaction volume increases over time, combined with other applications in the same Openchain ecosystem to create liquidity for digital assets issued on the chain, PoolSWAP is becoming one of the reliable and reputable DEX exchanges for investors around the world, with the criterion "A safe, fast, full-featured place to trade digital assets".
When will PoolSWAP Exchange launch?
The PoolSWAP Exchange will launch in May-2022
What is PS?
PS is the token powering the PoolSWAP Exchange. It is required for the governance of the decentralized exchange platform, as fuel for the perpetual decision-making process that will maintain the PoolSWAP DEX ahead of the curve in terms of innovation, operational model, listing policies, and other actions aimed at creating a sustainable value cycle for its stakeholders. Furthermore, the PS token is designed as a value capture mechanism and incentive vehicle that will allow the compelling attributes of the economical advancements it enables to scale with its adoption.
PoolSWAP Exchange Features
Overview
The PoolSWAP Decentralized Exchange (DEX) is the Automated Market Maker (AMM), rearchitecting some of the key elements to build a product that can leverage the entire performance of the Openchain architecture, to offer global, near-instant, inexpensive transactions among an expanding suite of assets.
The PoolSWAP DEX will feature an Automated Market Maker (AMM) application, enabling seamless p2p exchange (actually a peer-to-contract: P2C) of native Openchain tokens without the need of maintaining an order book.
You could think of an Automated Market Maker as a bot that’s always willing to quote you a price between two assets. These swaps instantaneously happen against assets that are pooled to provide liquidity. You can also provide liquidity in these pools and be rewarded based on their utilization. This allows essentially anyone to become a market maker on an exchange and earn fees for providing liquidity.
An AMM relies on a mathematical formula to price assets. Instead of using an order book like a traditional exchange, assets are priced according to a pricing algorithm.
This formula can vary with each protocol. For example, PoolSWAP DEX uses the industry standard "x*y=k" constant product AMM model, which has proven its reliability in existing implementations and has been formally modeled and verified. In this formula, k is a fixed constant, meaning the pool’s total liquidity always has to remain the same.
The performance of existing AMM platforms could be significantly improved by rebuilding them on vastly more scalable architectures. By reimagining an Automated Market Maker on top of a highly scalable architecture that is high bandwidth, low latency, and inexpensive, the performance of the swap processes can be drastically improved.
With significantly better performance, the scope of AMMs can be rapidly expanded, giving birth to new market opportunities. Perhaps the most important growth vector we will see will come when intuitive simplicity and ease of use will enable tens of millions, hundreds of millions, and eventually billions of people to interact with these new technologies, facilitating simple and instant exchange, at scale.
Swap
Users can trade or swap an amount of tokens for an automated computed amount from the second token. The Automated Market Making concept relies on a mathematical formula to price assets. Instead of using an order book like a traditional exchange, assets are priced according to a pricing algorithm. PoolSWAP DEX uses the Uniswap-like constant product formula x * y = k, where x is the amount of one token in the liquidity pool, and y is the amount of the other. In this formula, k is a fixed constant, meaning the pool’s total liquidity always has to remain the same.
There is a 0.5% fee for swapping tokens. As a part of this fee, 0.35% is split by liquidity providers proportional to their contribution to liquidity reserves. The contract will buy PS from the PS pool using the remaining 0.15% and burn it.
Liquidity
The liquidity pools emerged as an innovative and automated way of solving the liquidity challenge on DEXs. They replace the traditional order book model used by centralized crypto exchanges by using Automated Market Makers (AMM).
Liquidity providers are incentivized for their contribution with rewards. When they make a deposit, they receive a new token representing their stake, called a liquidity pool token or LP token.
The share of trading fees paid by users who use the pool to swap tokens is distributed automatically to all liquidity providers, proportional to their stake size. There is a 0.5% fee for swapping tokens. The PoolSWAP DEX economics model will be as follows: 0.5% will be the basic fee, from which 0.35% goes to the liquidity providers, and for the remaining 0.15% the contract will buy PS from the PS pool and burn it.
This 0.35% fee is split by liquidity providers proportional to their contribution to liquidity reserves. This is done via the following algorithm: whenever someone trades on the exchange, the trader pays a 0.5% fee and 0.35% is added to the liquidity pool. Since no new liquidity tokens are minted, this has the effect of splitting the transaction fee proportionally between all existing liquidity providers.
Swapping fees are immediately deposited into liquidity reserves. This increases the value of liquidity tokens, functioning as a payout to all liquidity providers proportional to their share of the pool. On PoolSWAP DEX, LP tokens can also be staked in a staking pool specific to each liquidity pool so that even more rewards are earned in the form of PS tokens.
Thus, a liquidity provider will earn rewards from 2 streams: the fees from the LP and PS for staking the LP token in a staking pool.
Keep in mind that the LP token is very important. In order to withdraw the stake in the liquidity pool, you need to provide the LP token.
Farms
Farms generate yield for liquidity providers that stake the LP tokens. They are meant to incentivize long-term liquidity by providing an additional revenue stream for providers. The rewards for farms are usually provided in PS tokens, but special farms with dual token rewards can exist.
Liquidity providers can use farms by staking the LP tokens obtained from providing liquidity in a pool. After doing this, PS rewards will periodically become available for harvesting. The rewards can be locked for a specific time with high APY.
PoolSWAP DEX Architecture
Router Smart Contract
The Router Smart Contract supports the basic functionalities performed for interacting with the Pair Smart Contracts. For better modularity, a Factory Module is added to hold the underlying logic that handles the Pair Smart Contracts.
The Router SC provides access to the Factory Module through a series of endpoints and view functions. Notably here are the createPair and upgradePair endpoints. The first one will be used to create a new Pair Smart Contract when there is no address associated with the two tokens intended to be used for the DEX activity. This endpoint is used only once per Pair creation. The latter endpoint will be used when a new version of a Pair Smart Contract will be developed and there will be a need to upgrade a Pair SC implementation. The usage of this endpoint is per Pair SC and can be used multiple times to upgrade multiple Pair Smart Contracts.
Router SC provides a series of view functions that will be used extensively on the DEX frontend. The getPair and getAllPairs view functions are of interest. The getPair function will get the associated Pair SC address for a pair of two tokens. Given the map-like implementation of the Factory Module storage that keeps the association between the tokens and Pair SC address, the order of the two tokens does not matter since the Factory Module exposes the same address.
Besides the above-mentioned functionality for the Factory Module, the two most important aspects of this is the ability to create Pair Smart Contract and upgrade a Pair Smart Contract. As described above, the Router SC is an interface between the user and the Factory Module. Deploying a new Pair SC results in a new address provided by the metachain for two associated tokens. The address is added to the Factory Module storage and can be queried by the user. Performing this action requires the need for the Pair SC bytecode.
The Router Smart Contract will also call several functions to issue and set roles for the OSDT tokens given by the Pair Smart Contract: Issue OSDT token - will issue a new OSDT token for the given Pair contract
SetLocalRoles - set local burn and local mint roles for the given Pair contract - this gives the possibility for the Pair contract to be able to mint and burn tokens locally.
Pair Smart Contract
The Pair Smart Contract consists of two main functionalities. The first one represents the liquidity pools associated with the two tokens that compose the second functionality, the swap activity.
Liquidity Pools
Because of the way a DEX is constructed, each Pair SC keeps two pools for each of the tokens that can be swapped between them based on an Automated Market Maker formula. Pair SC provides an endpoint to the user that is used to add liquidity into the pools as well as an endpoint to remove the liquidity added. Adding tokens into the liquidity pools is not a trivial task for the blockchain implementation and it would require multiple calls to the same endpoint to accept the tokens. The Pair exposes an acceptPayment endpoint which verifies if the tokens that are sent correspond to the ones that the Pair SC accepts. If the tokens do not match, then the Pair Smart Contract implementation will send them back to the user and the process to add liquidity would fail.
Upon accepting the two token amounts, the user has to perform the actual add liquidity operation by calling the addLiquidity endpoint from the Pair SC. The PoolSWAP DEX computes the exact amounts needed from the amounts sent by the user and based on the existing reserves as well as keeping the constant invariant from x * y = k formula unchanged. The unnecessary left amounts will then be sent back to the user. PoolSWAP DEX takes the concept of liquidity provider token (LP token) and goes a step further. For each Pair SC, when a liquidity provider adds his contribution to the pools, the Pair SC mints a specific LP Token equal in amount to the liquidity added by the LP and sends it to LP’s wallet. Anyone who possesses these tokens can claim their liquidity possession back. These tokens are issued in the OSDT format. Using these types of tokens we can simply anonymize the users as well, as in the pair contract there will be no evidence between the user and the provided liquidity. This makes the contracts easier as well. When the user sends these LP tokens to the Pair contract to reclaim his position, the LP tokens will be burnt.
The proposed architecture for the add liquidity process imposes the need for 3 separate calls to the Pair SC: two separate calls are needed to transfer the tokens from LP’s wallet to Pair SC: one call is needed to instruct the Pair SC that liquidity is added. The implementation of the Pair SC takes into consideration the extreme case when one of the two token transfer calls fails and the LP ends up with only one token amount being sent to Pair SC. An endpoint is added that can be used by LP to recall the unstaked token amount. Temporary storage is held for every LP until the add liquidity endpoint ends with success so that the LP can recall his tokens back at any time.
Removing the tokens from liquidity pools is done through a single payable endpoint that accepts only LP tokens specific to the Pair SC from which the LP withdraws its funds. Upon sending the LP tokens back to the Pair SC, it will compute the added liquidity for each token based on the amount of LP token sent, it will send the computed token amounts back to LP’s wallet and will perform a burn operation from the amount of LP token sent.
When the user enters the liquidity pool by calling addLiquidity the pair calculates the percentage of this entrance out of the total tokens existing in the liquidity pool using the x * y = k formula. For the computed percentage, the user is given LP Tokens for the selected pair. These LP Tokens are a must in order to get your liquidity position back, and to get rewards. When a liquidity provider “takes rewards” - (accumulated fees from the trades) he actually burns a set of LP Tokens and receives an amount of tokens A & B, which is computed according to the LP tokens amount. Computation will be done according to the percentage of the currently burnt LP Tokens as a percentage of the liquidity pool. This is the same formula as when the user entered the pool. However, as there were various swaps in the pool and there were accumulated fees out of these swaps, when the liquidity provider will get out of his position he will receive more tokens than he initially deposited. More details can be found in the Fees and rewards paragraph. The same number of LP Tokens will ideally represent a greater amount of tokens than initially deposited, because of the accumulated fees.
Swap Process
The second functionality a Pair SC exposes is the swapping process. Users can trade an amount of one token for an automated computed amount of the other token. The automated market-making concept relies on a mathematical formula to price assets. Instead of using an order book like a traditional exchange, assets are priced according to a pricing algorithm. The PoolSWAP Exchange uses the constant product formula x * y = k, where x is the amount of one token in the liquidity pool, and y is the amount of the other. In this formula, k is a fixed constant, meaning the pool’s total liquidity always has to remain the same.
Because of how the automated market maker is computed based on the constant product formula, multiple attack vectors can be associated with it. One in particular stands out called front running attack. An attacker can “wrap” a user’s order to swap two tokens with two of his own orders, taking advantage of the price calculations and being able to exchange the same tokens at a lower price thus obtaining a small profit with zero risk associated.
Pairs directly check whether the invariant was satisfied (accounting for fees) after every trade. This means that rather than relying on a pricing function to also enforce the invariant, pair smart contracts simply and transparently ensure their own safety, nice separation of concerns. One downstream benefit is that pairs will more naturally support other flavors of trades that may emerge (e.g. trading to a specific price at execution time).
To prevent front-running attacks, it’s vital to submit swaps that have access to knowledge about the “fair” price their swap should execute at. In other words, swaps need access to an oracle, to be sure that the best execution they can get from the SWAP is close enough to what the oracle considers the “true” price. While this may sound complicated, the oracle can be as simple as an off-chain observation of the current market price of a pair. Because of arbitrage, it’s typically the case that the ratio of the intra-block reserves of a pair is close to the “true” market price. So, if a user submits a trade with this knowledge in mind, they can ensure that the losses due to front-running are tightly bound. The frontend should ensure trade safety. It calculates the optimal input/output amounts given observed intra-block prices, and uses the router to perform the swap, which guarantees the swap will execute at a rate no less x% worse than the observed intra-block rate, where x is a user-specified slippage tolerance (0.5% by default).
We should offer 3 types of swaps: exact input in exchange for maximum output. Exact output in exchange for minimum input. Swap to the exact price. (with slippage/tolerance)
Fees and rewards for liquidity providers
There is a 0.5% fee for swapping tokens. This fee is split by liquidity providers proportional to their contribution to liquidity reserves. This is done via the following algorithm: whenever someone trades on the exchange, the trader pays a 0.5% fee, and part of this is added to the liquidity pool. Since no new liquidity tokens are minted, this has the effect of splitting the transaction fee proportionally between all existing liquidity providers.
The PoolSWAP DEX economics model will be as follows: 0.5% will be the basic fee, from which 0.35% goes to the liquidity providers, and the contract will buy PS from the OSDT/PS pool using the remaining 0.15% and burn it.
Swapping fees are immediately deposited into liquidity reserves. This increases the value of liquidity tokens, functioning as a payout to all liquidity providers proportional to their share of the pool. Fees are collected by burning liquidity tokens to remove a proportional share of the underlying reserves. Since fees are added to liquidity pools, the invariant increases at the end of every trade. Within a single transaction, the invariant represents token0_pool * token1_pool at the end of the previous transaction. Thus the constant K is changed by the returning fees as well.
The fees and rewards are taken only when the liquidity provider returns the given liquidity pool tokens. Thus, when the liquidity provider wants to get some of the rewards, he will actually release a set of LP tokens and get the computed amounts of Tokens A and Tokens B as rewards.
The PS token, the governance token for PoolSWAP DEX and other Openchain DeFi projects, will also be used to incentivize farms with a constant payout.
Farms
The liquidity pool tokens will be usable in the farming contracts. These users will be able to deposit their LP_OSDTs and will receive Semi Fungible tokens which will represent their farming position. These farms will earn extra yield for these users.
There will be ONE farm PER each liquidity token and one farm where users can enter with PS.
The process of staking and claiming rewards would be the following for those who stake LP Tokens:
The user enters as a liquidity provider in any PS/otherPair swap pool and will get LP-Token-PS-PairX. These LP tokens represent the user's position in the pool. If the user wants to claim some of his tokens back or the accumulated fees he must return the LP tokens and will receive the real tokens according to those.
The user takes the LP-Token-PS-PairX token and will stake it into the PoolSWAP-Farm-PS-PairX SC.
In order to take advantage of tokenization even in the PoolSWAP-Farm-PS-PairX SC the staking position is represented by a Farm Token. The rewards are in the form of the PS tokens received from the swap fees and from PER BLOCK MINTED PS.
The Farm tokens will be actually different for every Pair contract in order to know what kind of LP-Tokens has to be returned when the user gets out. The differentiation can be done by issuing different NFT tokens.
The process of claiming rewards is straightforward. The user has to give his position to the Farm SC and he will receive PS rewards + a newly created NFT which is identical to the one given, the only difference is that it will have its reward counter reset.
When getting out of the FARM SC the user will return some of the Farm Tokens and as we compute how much those tokens are valued, he will get it back as LP-Tokens of the given pool, plus he will get the rewards from the accumulated PS fees.
The process of staking and claiming rewards for those who stake PS tokens will be similar, with only a few differences:
The token staked will be PS. So when entering the PS Farm SC, a user has to stake their PS.
The rewards are only in the form of Per Block Minted PS.
There is only an NFT that represents the position in this Farm SC, because there’s only a PS Farm SC.
Token Listing
The listing process
Any project is eligible for listing. A simple criterion is to have an OSDT token, either natively minted on the Openchain Network blockchain, or bridged over from another ecosystem.
Important: only the token creator (i.e. holoride for $RIDE) can perform the listing process. In the initial phase, tokens can be paired with OPC (the native coin of Openchain network blockchain) and PS or USDT, and later on with USDC.
1. Register New Token
Add your token to the Openchain Web Tools as described here https://openchain.info/blog/openchain-web-tools-token-branding/. Once the registration process is complete, your token will be usable in the PoolSWAP Exchange for the next steps of the listing process.
2. Create Pair
You will be able to create a liquidity pool for your token with either OPC or PS. The USDC option will become available to pools that pass certain initial criteria. New pairs will not be automatically displayed in the PoolSWAP Exchange, but they can be imported by users in the near future. Note: only the token owner account can initiate the listing process. This way, token owners have control over the chosen pair and initial price.
Select “Trade -> Liquidity” from the top menu
On “Your Liquidity", Click on the “Import it"
Select the desired branded token and choose between pairing it with OPC or PS (the USDC option will be added later on)
Click on “Generate Pool Address” During the next step, the interface will show the pool contract address. Also, you will be able to set up your LP Token Name and Ticker (must be between 3 - 10 characters long)
Click "Create LP Token"
The next step requires you to click on Set LP Token Roles
3. Add liquidity
Token creators will set the parity between their listed token and its pair by adding initial liquidity. The ratio between the two tokens determines the initial token price.
Make sure you set the right ratio between the tokens, and that you have the specified amounts available in your wallet, then click on "Add Initial Liquidity".
After the add liquidity transaction is confirmed your Liquidity Pool will be successfully created.
In order to be able to see your pool in the Your Liquidity tab, you and your supporters have to import the contract address from the previous step.
Congratulations, you have created your token pair!
4. Enable swaps
The swap function is not enabled by default for new pairs. Initially, a minimum of $100k USD equivalent in liquidity is required to activate this function. If the liquidity in a pool drops below this threshold, swaps are disabled. Note that adding and removing liquidity is not restricted in any scenario.
On the testnet, make sure you reach out to a Telegram admin to quickly enable swaps for your test pairs.
Initial DEX Offering - IDO
An Initial DEX Offering is a crypto token offering run on a Decentralized Exchange (DEX). Liquidity pools (LP) play an essential role in IDO's by creating liquidity post-sale. A typical IDO lets users lock funds in exchange for new tokens during the token generation event. Some of the raised funds are then added with the new token to an LP before being returned later to the project.
What is a token offering?
A token offering is a fundraising method where a project or startup supplies a new cryptocurrency for sale. Crowdfunding methods can vary, such as using a centralized crypto exchange platform to manage the process, working with a local financial regulator, or simply doing it alone. Some investors purchase the coins for their utility, while others do it for speculation. For example, you might use the coin for farming, staking in a governance mechanism, or paying for transaction fees.
Presale List
IDO Launchpad Buy new tokens directly on OPC. Maximize your profit by participating in the Initial DEX Offerings. Create Presale
Create Presale
Verify Token
Follow the link https://poolswap.ai/create-ido or click “Create Presale”
Fill your token address in the Token Address box
Click “Next”
DeFi Launchpad Info: Enter the launchpad information and click “Next”.
Finish
Review your information and click “Create Presale”
Click “Confirm” in Metamask
Admin Panel
After creating IDO you will get the Contract address
Click “Enter admin backend”
Update the information then click “Update”.
Last updated
