Skip to content

Commit

Permalink
Cleanup tests
Browse files Browse the repository at this point in the history
  • Loading branch information
tasiov committed Jan 31, 2023
1 parent 66a3616 commit 25a701a
Show file tree
Hide file tree
Showing 11 changed files with 355 additions and 315 deletions.
46 changes: 27 additions & 19 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,21 +8,15 @@ Infinity Pool is an automated market maker (AMM) protocol that allows for the bu

This protocol is a derivative of the [sudoswap](https://github.com/sudoswap/lssvm) protocol written in Solidity. Infinity Pool makes use of the sudoswap design, but is written for [CosmWasm](https://github.com/CosmWasm/cosmwasm) so that it may be used on Cosmos SDK based chains.

## AMM Vs Order Book

The Infinity Pool protocol could offer some distinct advantages over the traditional order book model. Apart from being a fun tool for crypto natives, it allows for more expressive order types to be specified on chain. For example, by creating a one-sided pool with a special bonding curve, a user could effectively be creating a limit order that mutates after each trade it processes. This is difficult to do with the traditional order book model.

Additionally, there are special mechanics native to double-sided pools that are not as familar to order books. An NFT project could use a double-sided to pool to easliy create a market with liquidity on both the buy and sell side. Liquidity providers could also be incentivized to provide liquidity to the pool by offering a portion of the fees generated by the pool. If a community wanted to induce liquidity they could make use of this feature.

Most notably, this protocol would not necessarily hinder the performance of an on-chain orderbook as long as it exists on the same chain. Trades could easily be routed between the two protocols the same way an NFT aggregator like Genie routes between OpenSea and sudoswap.

## How It Works

As described by the sudoswap protocol:
> 1. Liquidity providers begin by creating a pool with specific parameters. They define which pools the assets will hold and the bonding curve which will be used to determine the price. Once the pool is created, liquidity providers can deposit tokens and/or NFTs into the pool. Once the pool is funded, liquidity providers can activate the pool so that it can begin trading.
> 2. Traders can then buy and sell NFTs from the pool. The price of the NFTs is determined by the bonding curve and the assets held by the pool. The price of the NFTs will change as the pool is traded.
> 3. Liquidity providers can withdraw their assets from the pool at any time.
### Creating Pools

> 1. Liquidity providers deposit NFTs and/or a fungible token into liquidity pools. They choose whether they would like to buy or sell NFTs (or both) and specify a starting price and bonding curve parameters.
> 2. Users can then buy NFTs from or sell NFTs into these pools. Every time an item is bought or sold, the price to buy or sell another item changes for the pool based on its bonding curve.
> 3. At any time, liquidity providers can change the parameters of their pool or withdraw assets.
Creating pools follows a three message process where the first message creates the pool, the second message deposits assets into the pool, and the third message activates the pool. The three messages can be concatenated into a single transaction by the client.

### Types of Pools

Expand All @@ -38,14 +32,28 @@ The `pool_type` parameter refers to the asset that the pool holds:
- A `Exponential` bonding curve has a slope that increases or decreases by a percentage with each NFT that is bought or sold to the pool.
- A `Constant Product` bonding curve specifies that the product of two reserve assets remains constant after every trade.

<!-- ## Contracts
### Performing Swaps

Traders can buy and sell NFTs from the pool. The price of the NFTs is determined by the bonding curve and the assets held by the pool. The price of the NFTs will change as the pool is traded.

### Pool Contract
The user flow for performing swaps is as follows:

- Indexed state
- Parameters drawn from the main order book
1. The user specifies the swap they would like to perform, along with the assets they would like to buy or sell. And queries the contract with these parameters.
2. The contract simulates the transaction, and returns a summary of the swap to the user.
3. The user then finalizes their swap by specifying their slippage tolerance and signing the transaction.
4. The contract performs the swaps, sends the requested assets to the user, and sends the accrued fees to their proper destination.

### Router Contract
### Features

- User slippage per NFT or per order
- Routes between pools and the orderbook -->
- Pool pricing indexed within the contract for optimized price discovery
- Respects listing price of marketplace contract
- Respects the minimum price of marketplace contract
- Respects the maximum finders fee of marketplace contract
- Respects the trading fee percentage of the marketplace contract
- Pool owner can set a finders fee that is paid to the finder address on a trade
- Pool owner can set a swap fee that is paid to the pool owner of a Trade pool
- Reinvestment of tokens and NFTs back into Trade pools based on parameter flags
- Flexible asset redirection for trader and pool owner
- Queries that allow for simulation of swaps
- User slippage tolerance for swaps
- User may decide to revert whole transaction or revert individual swaps using the robust flag
2 changes: 2 additions & 0 deletions contracts/infinity-pool/src/lib.rs
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
#![allow(clippy::too_many_arguments)]

pub mod execute;
pub mod instantiate;
pub mod msg;
Expand Down
4 changes: 3 additions & 1 deletion contracts/infinity-pool/src/swap_processor.rs
Original file line number Diff line number Diff line change
Expand Up @@ -76,6 +76,8 @@ pub struct Swap {
pub seller_payment: Option<TokenPayment>,
}

type IterResults = StdResult<(u64, PoolQuote)>;

/// A struct for managing a series of swaps
pub struct SwapProcessor<'a> {
/// The type of transaction (buy or sell)
Expand All @@ -97,7 +99,7 @@ pub struct SwapProcessor<'a> {
/// The latest pool that was retrieved
pub latest: Option<u64>,
/// An iterator for retrieving sorted pool quotes
pub pool_quote_iter: Option<Box<dyn Iterator<Item = StdResult<(u64, PoolQuote)>> + 'a>>,
pub pool_quote_iter: Option<Box<dyn Iterator<Item = IterResults> + 'a>>,
/// A list of swaps that have been processed
pub swaps: Vec<Swap>,
}
Expand Down
Loading

0 comments on commit 25a701a

Please sign in to comment.