Perp Listing SOL

Based on my own analysis of the on-chain trading activity we reached nearly $18M Volume with 239 users on BTC Perp in the first week. Given that SOL has usually slightly higher trading activity and we see a lot of position on Mango Markets based around SOL collateral, I’d like to suggest that we start a SOL Perp as soon as possible.

Given that BTC Perp’s contract size wasn’t chosen to maximum satisfaction. Does anyone have suggestions for the contract size?

3 Likes

something like $1-10 as a target for min order size is reasonable

for sol it can just be 0.01 min order/increment ($1.5 at current price)

On the spot side it’s min size: 0.1, min tick: 0.001. You’re proposing min size 0.01 and min tick 0.01?

I agree those are good params. We should deploy it on devnet and test and make sure UI can handle it being different from the spot side.

how does the system handle changes in those parameters (up or down).

i wonder why Serum was not built with this flexibility in mind

e.g., lower the order size from 0.1 to 0.01 is still “compatible” because 0.1 is a multiple of 0.01. but what if size is 0.001 and you want to raise to 0.01 – do the orders with precision down to 0.001 not fill properly? does it only impact old orders? do matches still work?

same issue on tick

1 Like

for tick – 5 significant figures is fine. so SOL now at $0.01 tick size sure

the annoying thing is when to decide to shift it upon large price changes

Right now it’s just not possible to change lot sizes after deployment. I think I could figure out a way maybe, but probably just not even worth it. Anyway we will have to migrate people every time we have a new version and we can do new lot sizes on migration.

Maybe a bit outside the scope of discussion on this post, but how would a re-deployment to change something (like tick size in this example) settle the previous perps? Just auto-close users’ positions against each other with a bit of heads up?

Not really sure. Would have to be very careful and make sure all the accounts that use the old contract sizes are updated. Probably not worth it. Better to just launch a new MangoGroup and let people switch over voluntarily.

1 Like

What do you guys think about using 2000 MNGO per hour for the SOL market along with (100, ^2) for the liquidity params? @AusteritySucks

1 Like

While I’ve argued on BTC-PERP that something like (200,^8) or (100,^2) is appropriate, I think that 200^2 is more appropriate in the SOL pool right now. SOL is making 10-20% moves daily, and I think it would be tough for makers to maintain that tight of a market. I also think SOL will be a more active pool, so I don’t mind 2k MNGO/hr.

2 Likes

I’m not currently making the BTC market but I am making SOL/USDC.

Agree with this, the volatility on SOL doesn’t appear to be going anywhere, think you’re right on the money with 200^2

I still think (100, ^2) is good for SOL. If it’s unprofitable to quote tighter than that, people will just quote wide and it’ll all balance out in the end. The system targets a fixed amount of MNGO to reward so if everyone widens by n bps, you’ll end up getting the same distribution.

I would argue that SOL’s volatility actually strengthens the case for (100, ^2) over (200, ^2), since the increased difficult of keeping up with the market just means we should make it more lucrative :slight_smile:

and I’ve previously argued for 2000 MNGO per hour for the BTC-PERP market and support it for this market as well

i think @iwillnotsaveyou makes a good point about the max_depth being a function of volatility.

but the suggestion to increase rewards for SOL-PERP, at the same max_depth at BTC-PERP, effectively does the same thing. just boosts the rewards which compensates for the higher risk one takes for being in that same max depth on a higher vol pair