Introducing Camelot: the ecosystem-centric Arbitrum DEX
As mentioned in our latest announcements, Camelot is a highly efficient DEX that is designed to support the Arbitrum ecosystem through building flexible and sustainable liquidity.
As we prepare for our upcoming launch, we have recently been sharing details for all of the core features, such as our NFT implementation of liquidity positions, our unique AMM, and our custom GRAIL/xGRAIL tokenomics. With that in mind, the below article provides a comprehensive summary for all of these features and our motivation and vision for the protocol.
Are you ready to join the Quest?
So what is Camelot all about?
Our main objective is to become Arbitrum’s native DEX by providing its ecosystem with a wide range of innovative features, enabling protocols to have a high degree of flexibility and control over their own liquidity. This also includes ways to effectively support new protocols wanting to settle on Arbitrum, offering them all the tools they need to launch, bootstrap liquidity, and sustain their growth.
How do we plan to achieve this?
By allowing those projects to leverage state-of-the-art functionality that can be easily integrated and built upon, as well as a permissionless toolset made to answer to their liquidity and incentives needs.
In order to succeed, we looked for the best ways to apply the sustainable yield narrative to a DEX and liquidity providing — creating innovative emissions strategies that leverage more sustainable tokenomics, aligning incentives with builders, users and the protocol.
Now let’s take a closer look at how we have put these different points into practice.
Our AMM is obviously an essential piece of the protocol and its ecosystem-oriented approach, and is designed with the following key principles in mind:
- A high level of flexibility and customization
- An optimized trading efficiency for users
- Providing support to protocols’ growth by adapting to their needs
It’s based on a dual-liquidity model for its pairs, meaning that both volatile (uncorrelated) and stable (correlated) assets can be traded with a more optimal slippage.
Camelot also introduces dynamic directional swap fees that can be based on market conditions and protocols’ specifics: not only does every pair can have its own customized fees, but they can also be set up with different values depending on the swap direction (buying or selling). This is a very unique lever that will give us the freedom to incentivize every pair differently, based on the correlation of its assets, the structure of the protocols, or even their own specific needs, but also to create custom fees redistribution schemes.
There are many possibilities: a project seeking to boost its trading volume, a newly launched protocol aiming to stabilize and limit selling pressure… It also opens the door to new implementations such as an automatic adjustment of the fees based on current market volatility.
Initially, every project launching on our AMM and willing to work with us will have its LPs configured with specific swap rates tailored to suit its own strategy. This will result in a win/win situation in which all actors are adequately rewarded, thereby fostering a fair and sustainable ecosystem.
One of the key pieces of Camelot is the introduction of a highly innovative approach to liquidity by creating a new layer of composability based on non-fungible staked positions, called spNFTs.
First, let’s start with some context.
Farming emissions and allocations have often been the weak point for many projects, and finding the right balance between a satisfying yield for liquidity providers and the holder’s dilution is no easy task.
Currently, in DeFI, DEXes incentives are in most cases distributed in farms based on the widely used implementation of the MasterChef model. Long story short, users stake LP tokens into the farms, and receive incentives based on their share of the total deposits.
One of the main drawbacks of this model is that it rewards every LP equally, whether it’s mercenary capital or long-term committed users, even if they each have a very different impact on the sustainability of the protocol.
We accordingly tried to find a solution based on the following ideas:
- Adequate rewards for every LP, based on their long-term commitment
- A modular and permissionless architecture made to easily evolve over time
- Reusable and more capital-efficient staking positions
That’s where our spNFTs come into play: they are basically non-fungible staked positions at the source of a new layer of composability for our AMM liquidity.
So how does it work?
When creating a position, the deposited asset is transferred to a contract, and a new spNFT is minted. This NFT acts as a transferable deposit receipt and is the only thing allowing a user to withdraw its attached funds, no matter who made the original deposit.
But staked positions are way more than simple receipts.
- Firstly, they have yield-bearing properties, meaning that they automatically generate yield rewards when their wrapped LP has been configured to receive our $GRAIL incentives.
- spNFTs also go with lock features: a position can be locked at any time for any length of time.
- If the position is a yield-bearing one, the user will receive a proportional bonus to earn additional rewards, with each LP having its own lock bonus settings.
Each spNFT has its own properties (amount, APY, boosts from locks or additional features…) and all the necessary interactions for its owner to easily manage it: they can be freely split, merged, topped up, transferred…
Finally, it comes with a complete and secure codebase designed to simplify integration and interactions with future contracts created to make use of those spNFTs. This is an essential point that we have taken particular care of to facilitate their adoption in the ecosystem.
This is a completely permissionless feature layer, which means that absolutely anyone can wrap any asset in an spNFT. Therefore, any protocol can leverage this stack, even if not directly incentivized by us, and freely integrate it into its own incentives layer. Users can create their own advanced custom strategies through an unlimited number of different yield-bearing staking positions for the same LP, with different amounts, lock durations, or complementary boosts mechanics.
spNFTs are also more capital efficient for LPs, as they act as receipts that can be reused/stored to generate another layer of rewards. Their design makes additional uses particularly simple to implement, a perfect illustration being their potential use as collateral.
As explained above spNFTs will provide a whole new layer of composability made to greatly improve liquidity staking, designed to be easily built upon. What if those spNFTs were to be used in a way that would allow protocols to permissionlessly incentivize and target a very specific type of liquidity, in addition to their yield-bearing properties?
We will demonstrate it below with our native solution built on top of the spNFTs: the Nitro Pools.
How do nitro pools work and what are the benefits of using them?
Nitro Pools have several characteristics in common with regular pools:
- a specific wrapped LP (or single asset) ➡only spNFTs made from this asset can be deposited
- a reward token and an amount of rewards to distribute
- a deposit start time
- a rewards distribution phase
From a user’s perspective, the process is fairly simple: you stake spNFTs into a Nitro Pool and get rewards depending on the share of the total deposits Users can deposit as many spNFTs as they wish to, as long as they meet the requirements.
It’s worth noting that once they have been deposited into a pool, it’s still possible for their original owner to interact with the spNFTs, adding more assets to them, (partially or completely) withdrawing, or harvesting their own rewards for the yield-bearing ones.
Nitro Pools have been designed so that anyone can freely deploy them, directly from our frontend. The process is completely permissionless, and designed so that protocols can use them to directly incentivize their liquidity as they see fit without any need for intermediaries.
The game changer here is the capacity for the deployer to add a set of requirements for a user to meet in order to have the rights to stake into a Nitro Pool, providing protocols with the ability to accurately target subsets of liquidity providers:
1) It’s possible to only allow positions with a minimum required amount to be deposited into the Nitro Pool. This is of course a very straightforward option that can be used to reward the biggest holders and contributors of a project.
2) Next are lock-based requirements, which will only reward users providing long-term liquidity.
They have the ability to allow only spNFTs with:
- an active lock with a minimum given duration
- an active lock that will last at least until a specified end time
Those lock-based requirements are an extremely powerful tool for a protocol to ensure stable growth over time, offering guaranteed rewards to the most loyal holders, thus spending its incentives significantly more efficiently and predictably.
3) Finally, deployers have the ability to allow only addresses from a given whitelist to deposit their spNFTs.
Protocols can use it in a variety of situations to target a predefined subset of users they want to reward and give them exclusive access to the newly created Nitro Pool.
Protocols leveraging those whitelists will be able to use them in a variety of ways: rewarding their most loyal and committed LPs over the long term, paying the winners of a contest, distributing compensation, and replacing an airdrop more efficiently…
Nitro Pools will be divided into two distinct groups on the app:
- Community pools
- Permissionlessly created by anyone
- Endorsed pools, which will be deployed by either the Camelot team or confirmed partners, and will come with even more flexibility and custom implementations
Through the prism of our two tokens, GRAIL and xGRAIL, we will examine a very important part of our tokenomics.
- GRAIL is Camelot’s native emission token and is a regular liquid ERC20 with a fixed maximum supply that will be reached in 4 years.
- xGRAIL, its counterpart, is a non-transferable escrowed governance token that can only be obtained through GRAIL conversion.
xGRAIL is not only a governance token, as its central use will be its ability to be allocated to special contracts, dubbed Plugins. The process consists of staking xGRAIL into a central contract that will assign the deposited amount to a plugin, in exchange for various benefits.
This choice of architecture allows us to have substantially greater composability, and to be able to integrate community or partners’ plugins while being able to leverage the allocated xGRAIL with additional functionality (governance, airdrops…).
Some of those plugins will be natively integrated into our contracts right from our launch:
- The first one on the list is the Dividends plugin. By allocating xGRAIL to it, users will receive a daily share of the revenue generated by the platform as real yield.
- The second native plugin, the Yield Booster, will leverage our yield-bearing spNFTs.
(It will allow users to directly allocate their xGRAIL to their staked positions in order to significantly improve their yield)
This xGRAIL plugin ecosystem has been designed to expand over time, and some new ones are already being integrated by our team! Combined with the addition of other plugins by the community or partners, this results in a token with multiple uses that can generate unique returns.
Both GRAIL and xGRAIL tokens will be distributed as farming rewards through our yield-bearing spNFTs.
- GRAIL can also be purchased freely on the market, unlike xGRAIL, which will technically be illiquid since it is non-transferable.
- GRAIL can be freely and instantly converted to xGRAIL at any time, with a 1:1 ratio.
However, to convert xGRAIL back to GRAIL, users will have to go through a vesting process, for which they will freely choose the vesting duration within a given range of 14 days to 6 months.
Consequently, the xGRAIL ➡ GRAIL conversion ratio won’t be fixed, as it will increase proportionally with the chosen vesting duration:
- a minimum of 15 days of vesting for a 1:0.5 ratio
- a maximum of 6 months of vesting for a 1:1 ratio
However, it is important to note that during this redeeming process, a portion of the xGRAIL being converted will be automatically allocated to the Dividends plugin, hence still generating revenue for the owner while being redeemed.
The last important point to mention is the existence of a whole series of deflationary mechanisms made to actively control the supply of GRAIL:
- Burned xGRAIL when redeemed for a lower ratio than 1:1
- xGRAIL plugins deallocation fee, buy back & burns from protocol earnings…
Together with the GRAIL hard cap, its carefully crafted emissions, and various additional mechanisms, we end up with a token whose circulating supply will be extremely well controlled, avoiding dilution for GRAIL and xGRAIL holders.
This is really just a brief overview of all of Camelot’s tokenomics, as all metrics, emissions, and allocations will soon be communicated in more detail.
Whilst our audits and last adjustments are being finalized, we are also now preparing to roll out our open beta — therefore providing the broader community a chance to initially test and familiarize themselves with the protocol.
As a team we pride ourselves on the quality of our work, with the open beta therefore including all features and functionality that will be live after the full launch.
The open beta will go live by the end of next week, and we are still estimating for a full launch towards the start of November. We will continue to release further details regarding both the open beta and the launch, so please make sure to only follow our official announcement channels.
Are you ready to join the Quest?
Main Telegram: https://t.me/camelotdex
Announcement Telegram: https://t.me/camelotdexann