On the remaining 9 Oracle Slots -- Prioritising Perp Listings

I think there was some good discussion on the Discord AMA last night about how exactly Mango should be prioritising the listings. In this thread I try to sum up the current facts and provide some data to suggest we move forward.

I may get some of the facts wrong so please correct me below if I’ve stated something inaccurate.

Current State of Play

The way Mango v3 currently works, we are limited to 15 “oracles”. An oracle being a price feed (Switchboard/Pyth) for a trading pair. Because Mango is currently using USDC as the home currency, these pairs currently are:


That’s six slots down, 9 to go.

Each oracle can be used to support either a token listing (for borrowing/lending and spot-margin trading) or a synthetic Perp listing. A token listing for borrowing/lending requires a Serum market, as this is the underlying spot market used on Mango.

Currently we only have one perp, BTC-PERP.

The issue of 15 slots limit will be resolved with time, however it’s not certain how close we are to that, and the depenency is apparently Solana 1.8 which enables a lot of optimisations to get more oracles supported.

This means, we have to make the most out of these remaining 9 slots, given we may be stuck with them for at least a few months.

What next? Spot vs Perps

I think the original idea was to get the “most” out of using an oracle slot by supporting it as a token for spot-margin and for perp.

Some have suggested that since Mango is on Solana, it should prioritise Solana ecosystem tokens, particularly because there would be a lot of Solana users storing their net worth in these and they would be useful to allow as collateral, and if they were allowed as collateral then may as well add a PERP as well to make the most of that oracle slot.

However, this comes at the cost of one of Mango’s competitive advantages: orderbook Perpetual contract trading.

Spot-Margin / Borrowing & Lending Collateral Quality

As we have seen with the MNGO token support, the collateral is not of high enough quality to allow for a low haircut. In fact, if you deposit $100 of MNGO on Mango, then you only get $20 worth of margin to open positions on perps or make other margin trades.

Collateral quality broadly is defined as something like:

(a) How good is the liquidity? (thickness of books)
(b) How much volume is there? (how much value is traded using (a))
(c) How volatile is the asset? (how reliably can we liquidate collateral / perp positions?)
(d) How stable is the supply mechanism? (this impacts the rate formula used for borrowing/lending of the asset, which is deterministic by utilisation and whatever Mango sets as the max)
(e) How much of the supply is owned by influential insiders who could abuse Mango to cash out where there is insufficient liquidity to sell?

All of these speak to avoiding massive insurance fund drawdowns and potential socialised losses and facilitating a robust and orderly market for key stakeholders:

  1. Normal mango traders on spot-margin
  2. Liquidators who have to clean up the mess when markets do get frothy
  3. Lenders who are providing the juice for spot leverage
  4. The perp traders who are relying on the integrity of their positions (to avoid ADL/social loss on themselves)

All this to say: collateral quality and perp market quallity matter, and have big implications if not taken seriously and parameterised accordingly.

Of course, we have to support MNGO because it is Mango. But should this be the trend of what we use remaining slots for in the short-term, to add collateral that is such low quality that we need an 80% haircut on its usage? Or, should we focus on using the lots to support a broader line of Perps, synthetically, which do not require any token support or Serum spot market activity.

Comparisons to other Perps Exchanges (dYdX and FTX)

One project that Mango has been compared to often is dYdX, who is one of the more successful hybrid DEXes, based on Ethereum, that runs perp markets. Their product is inferior because it is requiring users to have USDC collateral, whereas Mango is multi-collateral. Nevertheless, here’s their list:

The volume here indicates that it is quite dominated by alternative layer 1’s. They have certainly not prioritised to add ERC20 projects, but instead chosen to let traders use USDC to trade whatever crypto assets they want.

Another interesting dataset is FTX. Here is the past 60 days volume (to help control for “hype” effects without unfairly disadvantaging recent listings) for all 159 perps listed there: Top Perp volume - HackMD

The top 25 I provide here:

So, aside from RAY and SRM there’s not much of a focus of the volume on native Solana tokens

There are some ERC20’s where they are Sollet-wrapped. But ADA, XRP, DOGE, AVAX, DOT – these are not assets that have a Serum market.

Next Steps

The main issue I’m trying to identify here, which others last night on Discord expressed as well, is that the most popular perpetual contracts out there in the market are not necessarily the popular SPL token and Serum spot markets. Given the limited slots, we need to choose wisely between whether we are pushing to support the borrowing/lending and spot-margin side of Mango or the Perpetual contracts market on Mango.

So what I suggest is:

  • List RAY as this meets similar standards as SRM and would be suitable for both sides of Mango’s projects.
  • List perps on ETH, SOL, SRM, RAY, USDT, MNGO. (this takes no slots)

This leaves 8 slots remaining.

For those 8 remaining slots we should add perpetuals on:


It’s very likely based on voting dynamics on Mango that SBR and COPE will just be pushed through as tokens, which takes up 2 slots. And means that the above 8 suggestions need to be economised on too.

But overall, the community should decide what direction it wants to go on either in supporting Perps market in shorter term or just continuing to use slots to support Solana SPL token projects.


I see a spectrum of strategies:

1) chase dydx right now and only list more perps

PRO: great appeal to onboard more users to solana, also dydx doesn’t have a great collateral engine rn
CON: mango lacks on other features & they are spending a ton on incentives rn, people are busy farming

2) lean into the solana ecosystem, offer increasingly more leverage on spl shitcoins

PRO: very unique products and easier composition with other protocols (something dydx always lacked)
CON: less appeal to the broader crypto scene, risk factors and haircuts will be a constant issue

3) hybrid approach

PRO: experiment with different ideas and see where product market fit lies, try to disprove our assumptions
CON: we will quickly run out of markets or be very selective

Limitation of the current design can be solved by simply redeploying mango with a code constant changed and getting more RPC nodes. It’s going to be mostly operations overhead, but can all be done in a few days. Extending the code to handle multiple versions of margin accounts is also possible but might be more dev time investment. To prepare, we should make sure that future proposal start aligning liquidity incentives to run out around the same time.


The mango community needs to focus on what type of audience we wish to market towards. Focusing on L1 perps with a small blend of high quality Solana Ecosystem tokens is probably the perfect mix. RAY/SRM are high quality Solana specific projects that aren’t necessarily the highest volume but provide us with a strategic reach to the Solana ecosystem. SBR/COPE are passable at best not really the highest tier projects but I can live with them being added considering that they will probably pass.

In general a more professional approach in the early stages will be key to the growth of mango in terms of attracting serious investors/market makers with more capital. Meme coins will just dilute the brand and will hinder mangos wider growth. Of course, there is a place for these coins to be added but given our current limitations we should focus on perps with greater market appeal.

Why focus on Perps?

Perps are the bread and butter of what mango is about. The revenue collected by mango is currently only coming from perp markets so obviously this should be a major focus of the project. Bringing in solely Solana projects just because they have spot markets will definitely not bring this wider userbase and will lead to dead markets. High volume markets with lower volatility will be a lot more profitable for mango and lead to more people actually participating in market making.

Oracle Priority

Potential listings stated by Austerity:


These choices are solid additions to increase the overall usage of the mango platform. I would add FTT to this list which has the 5th largest 60 day perp volume on the FTX exchange based on the image posted. FTT has the benefit of being supported as a serum market currently (Allowing it to be used as collateral) and has a wide market appeal in the general Solana ecosystem.

The focus should be on quality L1s with high volume/lower volatility. While DOGE does have the wider market appeal from retail investors and high volume it is a meme coin. There is value in including something like DOGE but I would rank it lower within this list to prioritize higher quality projects.

My revised list of 6 if SBR/COPE pass:

  • ADA, DOT, LUNA, FTT, (2 Wild Cards from: AVAX/ATOM/LINK/DOGE)

This list prioritizes 4 strong projects with strong use cases that have a high likelihood of being supported on serum in the future. After 1-2 weeks of additional discussion we should propose 2 wild cards from the remaining list. Also worth mentioning that LINK does currently have a serum market and can be used as collateral.

Timeline and Priority

  1. ETH-PERP: The next obvious choice after the addition of SOL-PERP goes live. While there isn’t specifically high volume of ETH on the mango platform I believe this lays the ground work for a more complete project. Serious traders will be looking for this market and is necessary before even considering other PERP listings.

  2. ADA, DOT, LUNA, and FTT perpetuals + FTT spot market: The next step as described is to list a quality set of projects that have a wider market appeal. This will be a huge marketing play for mango and attract a more serious trading crowd. This puts a focus on L1 chains that currently can’t be traded on the rest of Solana with the exception of FTT. Most likely this will bring traders from outside Solana and even hype from Solana users that do wish to trade these other chains.

  3. Wait some time after the core release to discuss and include 2 wild cards from (AVAX/ATOM/LINK/DOGE) or include more projects based on the needs of mango. Assess if the liquidity is adequate on the current perpetual markets to justify adding more.

1 Like

FTT sounds good to me as well.

Just an adjustment on timeline, dont forget:

  • Next to ETH-PERP should be SRM-PERP, USDT-PERP (useful to play the “tether CDS” trade on either side), MNGO-PERP (filling out the existing spot token cases)

The point about revenue is really important addition too. Spot-margin is more of “loss-leader” to support PERP which is the real moneymaker, and bolsters the point of focusing on this. Although I guess we could vote separately to squeeze some revenue out of lending too, some other time.

Yes, makes sense batch ETH/SRM/USDT/MNGO together or do ETH first and the rest later depending on how the SOL-PERP listing goes. This will give mango a nice base layer prior to having some of the advanced order types most traders are used to.

In addition, adding USDT-PERP brings up an interesting question when it comes to the mango emission for perp markets. How should the emission rate be decided for perp listings? We could opt for 2k MNGO/hr static across all the markets, but providing liquidity for a USDT-PERP has 0 volatility and does not deserve the same reward. Maybe we could opt for a tier system where we rank listings based on trading volume and tweak the emission rate based on each tier.

I think USDT-PERP would probably have to have 0 rewards and fend for itself.

But, the whole reason for it to exist is for tail-risk on stablecoins. And USDC could suffer similar risk.

Which brings up an even more interesting question: is Mango running quanto contracts where the index is /USD and pnl /USDC? Or are the indices all pure /USDC. This is a detail, but highly relevant if we have a massive US regulatory crackdown on stablecoins where both USDT and USDC may trade at discounts. At which point, whether the index is USDT/USDC or USDT/USD is important (same for all the other indices).

For the additional oracles, I like the sound of ADA, AVAX, DOT, LINK, DOGE, LUNA, ATOM, FTT.

If SBR and COPE pass (and I strongly encourage everyone to vote against that), then I would remove LINK and one of LUNA/ATOM.

While USDT-PERP is nice to have, I don’t think we should list a market without any incentives at all–it just doesn’t look good to have an empty book.

Yeah I debated this point for a while and decided to just consider USD == USDC.

The problem is there is no such thing as USD. Every exchange’s USD should be treated as its own stablecoin because crackdown on an exchange’s banking relationship sends the BTC-USD on that exchange higher. So only using USDC quoted markets for oracle prices is more accurate. However, it’s very tough to use just USDC markets because oracle providers have to provide them and they’re often much less liquid than the USD quoted markets on the same exchange.

ok so really they are quanto – maybe one could argue FTX is also quanto but they do mix USD (“real”) and USDC/other stables, so “less” quanto

Something I haven’t seen touched upon (which might have been discounted in the chat already) is: the limitation is in slots per Mango Group. It should be possible within the current Solana limitations to have multiple Mango Groups.

There could be a default Group for most users (effectively what we have now). And a different group purely for Solana-based tokens. And another group for bridged tokens from other chains. And…

The obvious problems with this are:

  • Headspace. Things are complicated enough for most users. Multiple groups with multiple accounts will cause more confusion.

  • Cross-margining works within a group but not across multiple groups.

  • The UI isn’t built for handling multiple groups.

  • Each group will require substantial overhead like keepers and liquidators.

Cross-margining only being within a group would mean it would make sense to cluster tokens people wanted to cross-margin within the same group (possibly duplicating some markets in multiple groups). Would this mean we’d cluster all L1 tokens in one group? Or all Ethereum tokens in one group? Or something else?


this is really bad. I think one of the major selling points of Mango is that you cross-margin across all your deposits and positions. i dont think this is something that should ever be compromised in the experience


I don’t disagree it’s bad!

However, I seem to be more skeptical than others that Solana 1.8 will solve all our problems, and I’m reluctant to go ‘all in’ on that.

My thinking is: in 1 year’s time, if we’re still limited to 15 market slots (or otherwise limited…) which of the following situations do we want to be in:

  1. The current group, with the slots prioritised appropriately?
  2. The current group, with the slots prioritised appropriately, plus one or two (or more) additional groups that greatly expand the range of tokens but are limited to cross-margining within the group?
  3. Someone taking the Mango code (it’s open source) and implementing step 2 (multiple limited-cross-margined groups) themselves?

I can see pros and cons for all 3, and I’m not trying to lead in any particular direction. I really think we should make a conscious decision on it though, rather than drift into whatever happens.

1 Like

Are we able to recycle slots? So, if we are in that situation in 1 year’s time, can we just drop some low-performing pair’s slot and replace with a better one?

I just think having multiple margin wallets is a non-starter UX-wise. I don’t see how having to move funds between mango accounts is acceptable. And I’m not clear enough on the technical details to figure out the probability of we are really in a situation where it’s 1, 2, or 3.

I think recycling slots is somewhere between ‘hard’ and ‘impossible’, but I’m not certain.

I take your point about the UX, and have been wondering if there’s anything to mitigate it. I still don’t think it would be good, but:

Go to trade.mango.markets for the current group and behaviour.

Go to trade.papaya.markets for a completely different branded experience, with a different group and a different set of tokens. The different set of tokens includes the commonly-traded ones from Mango, plus more that are likely to be cross-margined and traded together. Maybe it concentrates on wormholed tokens?

Go to trade.coconut.markets for a differently-branded experience again. Different group, some shared with other groups, but the remainder focused on Solana ecosystem tokens.

An additional constraint in choosing tokens would be to pick the ones all commonly cross-margined and cross-traded to minimise wallet-shuffling.

It’s not really something I would want to choose though.

The above scenario could just happen without Mango involvement, if someone forms Papaya Markets and Coconut Markets, forks the code and sets them up. We’d end up with multiple margin accounts and wallet-shuffling but with a lack of Mango-ness. (And so what? Maybe that’s preferable? I don’t know.)

I would definitely like to hear more about why you’re skeptical that expanding beyond slots per mango account/wallet is possible. If there are serious core scaling issues with Mango it would be nice to have an open technical discussion for those on both sides so the community can understand it fully.

Until the technical facts are properly understood it’s difficult to make a call on whether doing something like multi accounts w different assets is the right way to go.

1 Like

I think my skepticism comes in part from the changes in 1.8 being complicated and unclear how they’ll interact, combined with the obvious problems in 1.6 still being problems when they shouldn’t be.

My understanding of the relevant 1.8 changes:

  • The compute limit is going to be applied per transaction, not per instruction
  • The transaction size limit of 1232 bytes stays in place.
  • A new transaction format will allow you to use a single byte to represent an address instead of the current 32 bytes

The effective reduction in the compute budget is going to hurt - there have already been problems hitting the compute limit in an instruction, but now that limit will apply across all instructions in a transaction. It’s not clear how this will affect code like the marketmaker that tries to batch things in a single transaction, and while splitting cancels and orders across multiple transactions is straightforward, it quickly gets complicated if some succeed and some fail. I know the marketmaker can work around this, but it’s not making things better. I’m not sure how other components should handle this.

Having multiple ‘maps’ of single-byte addresses will reduce the chances of hitting the transaction size limit, but will complicate the programming a lot.

Take OpenOrders as an example. When you place a Spot order, if you don’t have an OpenOrders account, it’s automatically created, initialised and used.

OpenOrders accounts are the biggest reason we hit transaction size problems - we send every one of the user’s OpenOrders accounts to a PlaceOrder instruction - so this is one area where we want to use the new address mapping.

But the map is unchangeable once created, and they say to wait until it’s finalized before using it, so the new flow is to create and initialise the OpenOrders account, delete the old address map on Solana, create a new address map on Solana, wait for it to be finalized (how many seconds?) and then place the order. It’s not that we can’t do this, it’s just that it’s not necessarily better. Or perhaps it’s just not unequivocally better on all measures.

My skepticism increases the longer problems continue with RPC nodes and with getMultipleAccounts and with websockets. These are much simpler problems than re-doing the whole transaction format, but they persist. This worries me.

Maybe we can get a good, workable Mango on top of these changes. Maybe I’m worrying over nothing (again - it’s a habit of mine). But I don’t think its a certainty yet.


I think it makes sense to offer tokens that allow traders to express diverse opinions but equally value Market Cap as well as Volume. ETH, ADA, BNB seem to be great choices based on Market Cap as well as Volume.

About the technical issues: we currently use a statically reserved memory layout, all parameters have been tuned to achieve a reasonable balance between the account size (which is the same for all mango accounts) and the amount of tokens that can be traded: the struct is defined here.

There are many ways to optimize it. We are for instance doing already some dynamic layout work to allow trading on a limited subset of spot markets at the same time (layout is allowing 16 but only 9 can be actively traded due to solana account limits). The contract is ensuring that a user never trades more than 9 markets at the same time. We could port this optimization probably to perp markets, but we shouldn’t loose our focus here and think too short term.

With the next version of solana some of these optimizations will become unnecessary. So not doing them right now, might play a long term game. I personally try to prioritize work that will benefit Mango in the long term rather in the short term as I think of this as a Marathon rather than a sprint.

From my experience it is common for young application projects to optimize aggressively too early towards a certain platform and be superseded by projects that simply build the same feature, once it is really easy to do so. To some extend this also describes the SOL / ETH dapp macro rn, but we should specifically think about this with a lense on the Solana ecosystem when choosing our steps.