Add core math packages (using wasm) & high-level typescript sdk

[wjthieme]

core lib

Add two new packages to the monorepo

• rust-sdk/core
• ts-sdk/core which is the wasm version of rust-sdk/core

This approach is great because this allows us to have a single source of truth for math functions that are used throughout other libs (and potentially even the program). Writing it once means that the implementations will always be identical regardless of which platform you are on. Also means we only have to write tests for them once

The wasm lib currently only builds with std enabled because of something in tsify. This inflates the wasm bundle by quite a bit (65Kb instead of 25Kb). I opened a ticket: madonoharu/tsify#56. This only affects the ts-sdk/core and is a bundle size thing so not the end of the world. All code behaves identically as if it was built with/without std

This PR only contains basic test cases and does not test for any of the more tricky / edge cases for swap quoting. My brain is fried from looking at tick array traversal and bit math the past couple of days so I'd like to continue with other parts of the SDK and revisit this later.

High Level TS sdk

Goals:

• Easy to use (over raw performance)
• Keep as simple as possible (no custom tx sending, confirmation logic etc.)

Still missing (added TODOs for these but not strictly necessary for this PR):

• Transfer hook Support
• Some unit-tests

vitest

I had to move away from ts-mocha (hasn't been updated in more than 2 years 😮) because it would not work correctly with the esm/monorepo setup. I chose vitest which is built esm-first and we already use it in other repos. Added benefit: the test suite seems to run a little bit faster now

note: Since this is not added to publish workflow yet this will not be deployed yet on tag

[sam0x17]

few nits but looks good!

[sam0x17]

this is looking good my only thought is to use checked_div instead of / so we can avoid any unintended divide-by-zero errors

[wjthieme]

@yugure-orca I think this now contains all the core math and quoting logic for whirlpools 🥳. I am however not 100% confident yet that all the logic is implemented correctly 😬. Especially some of the round ups and downs when doing when doing muldiv and bitshifts

As stated this same logic is exported through wasm (still with std lib but we can fix that later) so rust sdk and ts sdk will share the exact same logic 🎊

(If in the future we ever want to make sure that the core logic is shared between the SDKs and the program that should theoretically be possible with the way I set up the core package)

[sam0x17]

lgtm, final versions of the macros look sound and well tested

[yugure-orca]

Thanks for hard work!
WASM integration is really interesting.

I have not reviewed the following 2 files yet, but push current review comments.

• core/src/math/price.rs
• core/src/quote/liquidity.rs

We have added comments, but my overall impression is as follows:

• u128 is often used as type for token amount. is it impossible to u64 with wasm ?
• I believe we should use same logic to the latest contract because it have been battle-tested and audited and reviewed by us.
• we need to be careful for negative tick_index, especially with % (mod) operation.
• I think panic! is the end of the world and should not be used for invalid input.
• .unwrap() can be used if we can assure that it will not lead to panic. (logically correct but compiler cannot determine)
• .saturating_x function is so dangerous because it will drop overflow and underflow errors.
• If contract uses checked_add or checked_sub, it is safe to use them in client-side.
• Is it impossible to use Result<T, E> and Option with wasm ? I noticed that many Result and Option type is removed and I feel that those changes are unsafe.
• Math for TransferFee calc, Slippage calc and Trade fee calc are similar, but I think "integrated" function is not intuitive as one reader.

[yugure-orca]

Reviewed the following 2 files 🫡

• core/src/math/price.rs
• core/src/quote/liquidity.rs

need to be careful:

• we need to use sqrt_price (tick_index to sqrt_price conversion is safe, so if devs have tick_index only, they can safely convert it to sqrt_price) because tick_current_index is not exact pool price.
• in this area, many overflow/underflow risk exist, so Result type and checked_x function will help us (no saturating function)
• we can use real value of SOL/USDC for PriceMath logic testing.

proposal:

• nit: slippage_tolerance: u16 --> slippage_tolerance_bps: u16
• token amount based slippage is sensitive and easy to fail transactions (so we may add improved instruction in this area, so reserving "general" name may be nice)

[yugure-orca]

pushed some comments

[yugure-orca]

@wjthieme
At least, Whirlpool Program uses only 2 logic, so if we truely 4 logic, it is critical issue.

In ExactIn:
[ for input token ]

• user specify "Pre fee amount (transfer fee included amount)"
• the program calculate "Post fee amount (transfer fee exluced amount)"
• swap core logic use "Post fee amount" (swap core logic don't need to handle transfer fee)

[ for output token ]

• swap core logic generate output amount and it is "Pre fee amount"
• the program calculate "Post fee amount (transfer fee excluded amount)" and compare it with other_amount_threshold

User spacify amount transferred from their wallet as amount, and specify amount received as other_amount_threshold.

In ExactOut:
[ for output token ]

• user specify "Post fee amount (transfer fee excluded amount)"
• the program calculate "Pre fee amount"
• swap core logic use "Pre fee amount" (swap core logic don't need to handle transfer fee)

[ for input token ]

• swap core logic generate required input amount and it is "Post fee amount"
• the program calculate "Pre fee amount (transfer fee included amount)" and compare it with other_amount_threshold

Since the keyword adjust is somewhat ambiguous to me, I would like to see three separate functions (TransferFee, Slippage, SwapFee) for different purposes.
The fact that they call a common code internally would be a way to maintain readability.
However, if the common function branches for each AdjustmentType, it would be safer to separate the functions originally.

[yugure-orca]

pushed comments for previous review comments

[yugure-orca]

@wjthieme
If sqrt_price is on between tick_index = 0 and tick_index = 1 in USDC/USDT pool, tick_current_index is 0.
I think prev_initialized_tick(0) will be -1 and skip 0.
So pool liquidity calculation will be de-sync.

[yugure-orca]

pushed comments for review comments on #262

[yugure-orca]

Thanks for your hard work.

Yep, many code looks much cleaner to me.

I made some comments, but I would like to see the whole thing for the last time now. Therefore, I think it would be better to merge the PR once only the commented parts have been resolved and work on another small PR thereafter.

We can write the core logic in Rust, so I think it's safer to use the contract code as is as much as possible, although there is no way around things like U128/u128 conversions.
If the logic is the same, I don't have to review it as so carefully, and we can continue to have the peace of mind that it has been battle-tested.

[yugure-orca]

Could you add test case with the following condition ?

[case1]

• transfer_fee_rate: 10_000u16 (100%)

• transfer_fee_max: 500u64

• token_amount: 100_000u64

• expected: 100_500u64

[case2]

• transfer_fee_rate: 10_000u16 (100%)

• transfer_fee_max: 500u64

• token_amount: u64::MAX

• expected: overflow

The reason why I commented that I want to use proven code (as-is), such as SPL-token code and whirlpool contract code, is to prevent such regressions. It is very sad as a reviewer to create another bug that has been solved before.

[yugure-orca]

I need to look the remaining 2 files:

• rust-sdk/core/src/math/tick_array.rs
• rust-sdk/core/src/quote/swap.rs

pushed some comments for previously commented part. 🙏

[yugure-orca]

Thank you for your grate work to integrate Rust/TS core logic! 🚀

[yugure-orca]

nit: AMOUNT_EXCEEDS_MAX_U64 -> ARITHMETIC_OVERFLOW because no into() ops here.