The time constants that we have for defining the waiting periods should be moved into storage so they can be manipulated in the tests.

We need a treasury system to support the deposit of tokens to support the order matching mechanism.

The treasury should be able to accept deposits and link them to orders. It should also be able to return tokens after orders have been cancelled.

We need a mechanism to collect the current price of the token pair from an external source (oracle / dex).

For the PoC, this should be the simplest source possible (probably a DEX feed)

The swap execution will need to be supported by a treasury mecanism that supports multiple token types per address

https://github.com/tezos-checker/segmented-cfmm/blob/master/ligo/errors.mligo

Use the same approach to use error numbers instead of strings

Based on the new doc we should create the clearing price calculator to support the design doc.

It should receive a batch (i.e. a number of swap orders at different levels and sides) and an Oracle price. From this we need to calculate the clearing price level.

marigold-dev/deku#798

We need build and deployment tooling to support the rapid development on the PoC

For the PoC we need to be able to deploy to a testnet easily (this has mostly been done) but we need to test after merging the components and then fix any deployment issues.

We should also target Ghostnet for deployment

https://ligolang.org/docs/advanced/interop/

The separate components like treasury and matching won't be individual contracts for the POC so we should remove the contract entrypoints and switch to method calls from the main slip contract

https://ligolang.org/docs/advanced/inline

Annotation of pure functions should help reduce the size of the contract

In order to deal with partial matches of fractional amounts we need to add a precision field to the tokens:

tzBTC -> https://tzkt.io/KT1PWx2mnDueood7fEmfbBDKx1D9BAnnXitn/tokens/0/metadata 8 decimals

USDT -> https://tzkt.io/KT1XnTn74bUtxHfDtBmm2bGZAQfhPbvKWR8o/tokens/0/metadata 6 decimals

Objective
Deadline: 2022-09-09 00:00:00

Objective
Deadline: 2022-09-16 00:00:00

We need a design do to show how all the components fit together

Because of the automatic swapping process, we need a treasury address for supporting this. This treasury address needs to support XTZ and other tokens in Tezos.

What will need to change:

• Design doc
• Code references to tokens
• Price poster (tzBTC/USDT isn't directly available from the source we are using so it will need to be calculated from XTZ/USDT and XTZ/tzBTC)

Implement the library which supports floating-point numbers. In my opinion, I will include the math-lib-cameligo as the submodule.

We need a very simple UI to enable processing the swaps. This needs to be functional - not pretty

Objective
Deadline: 2022-09-02 00:00:00

We should try to use the ligo packager where possible rather than submodules

• We need a mechanism to match off orders either completely or partially (this would mean leaving the remaining un-filled part of the order until it expires or is itself filled or partially filled).
• Any orders that have expired should be cancelled

Objective
Deadline: 2022-09-09 00:00:00

We need to run through a complete test which means

• Deployment to testnet
• Deposits (using UI or CLI) - at least 15 swap orders
• Posting of prices
• Successful execution of swap orders
• Successful redmption

We need a command line or script to source an exchange rate for the given test pair and post to the contract

I need to add breathalyzer tests to make sure that everything of the token contract which follows the FA2 standard is correct

The exchange rate uses the swap type which includes token_amount. This doesn't really fit and the rate should use just a token pair instead

we have to decide and find how do we want to deal with the math file and prices calculation, and write tests (maybe implementing the sheet Jason made in excel but with tests)

CI needs to be fixed to use the make file and run the tests

Add the additional steps that need to be taken after the initial PoC to move to market

once we know the clearing level (which has been coded) we can progress to the settlement of the orders. Any orders at or below the clearing price can be settled pro-rata (first come first serve), this could include partial fills. All others are not executed.

We need to create some tokens on the testnet to represent tzBTC and USDT because they don't exist on Jakarta net.

The tokens should have the same metadata as those on mainnet, at least tokens names and decimals etc

https://tzkt.io/KT1PWx2mnDueood7fEmfbBDKx1D9BAnnXitn/tokens/0/metadata <- tzBTC
https://tzkt.io/KT1XnTn74bUtxHfDtBmm2bGZAQfhPbvKWR8o/tokens/0/metadata <- USDT

In order to make the UI work easier, we need a single or multiple on-chain views that provide the following:

• current batch time remaining? (0 if no batch open)
• current order book (not sure this will be in the production version but will be useful for testing)
• current orders for given user
• summary of previous orders for current user

The batching mechanism should work in the way that the design doc states.

Historic rates were a nice to have but we don't need them so I will remove

Objective
Deadline: 2022-09-02 00:00:00

Test framework should support testing of the initial clearing price calculator to support the redesign

Objective
Deadline: 2022-09-09 00:00:00

When we deposit a swap in the testnet contract, this should be reflected in the wallet amount. I.e. a swap deposit should remove an equal amount of token from the trader/user's wallet and that token should be in the contract's treasury.

We need to test that this is actually happening on the testnet.

The contract storage that we build doesn't fit now the 3 components are merged. It needs to be updated

Initial Test for 0-slip PoC

The following should be run on the deployed contract for both initially supported pairs - XTZ/USDT and USDT/tzBTC,

Scenario 1. Simple Matching Swap

Setup:

• Update Oracle price for swap.
• Place equal and opposing swaps from different wallets at exact price and correct amounts

Result:

• The swaps should match and the treasury should redeem the correct amounts to the respective wallets

Scenario 2. Simple Non Matching Swap

Setup:

• Update Oracle price for swap.
• Place first swap
• Update oracle price again
• Place opposing swap from a different wallet at a different price

Result:

• The swaps should not match and deposits be returned correctly after expiry

Scenario 3. Partial Matching Swap

Setup:

• Update Oracle price for swap.
• Place first swap
• Place equal and opposing swap from a different wallet at the same price but differing amount.

Result:

• The swaps should partially match and the treasury should redeem the amounts correctly
• Any remaining non matched amount should be redeemed to the correct wallet after swap expiry

To be able to test the contract we will need tokens and XTZ in a defined wallet. We will be testing two pairs for the PoC - XTZ/USDT & UDST/tzBTC

• Create re-usable test wallets (two minimum)
• Get XTZ, tzBTC and USDT from faucets and transfer to wallets ready for testing

We need a consistent set of types used in all components for items that will be used by multiple components