Ideas around Pangolin Development Roadmap
The first thing I think is important to discuss is the two main categories of work that will need to be performed. For me, this is:
- Foundational
- New features
I believe for us to be able to deliver code to a high quality and a good velocity, it’s important to focus on the Foundational pieces first. I’ll go through those first and then talk about the Features that we could/should see on Pangolin.
Foundational
In my view, the quickest way we can deliver new features is to leverage composability across the entire stack, while ensuring the code is of a high standard with high levels of security.
This could be achieved by having a “beta” version of Pangolin live on the Mainnet. This version would include the new features being worked on and ensure that we could widen the testing to a broader audience to allow more edge cases to be tested. The importance of this beta version on Mainnet is that we can test in production with a live dataset and the risks still being there. This will drive quicker adoption but also mean that if there are bugs, they’ll be discovered on smaller dollar value transactions.
How do we get there?
There’s a few key foundational elements that will need to be resolved.
Security
This is the biggest concern for me. When deploying Pangolin contracts and interacting with the contracts how do we ensure that we protect ourselves from bad actors. See Sushi for reference. This means decentralization of the control/power of the keys.
Currently there are three options I see:
- Implement a multisig on the Avalanche C-Chain
- Use a Multi Party Computation Wallet https://blog.ledger.com/mpc_readiness/
- Assume that Avalanche includes multisig as part of Apricot and/or future releases and wait for it.
In Ethereum implementing a multisig is not supported natively. We can do it on the Avalanche C Chain via a Smart Contract and this is a viable solution.
MPC wallets such as those offered by Fireblocks may be a good option https://www.fireblocks.com/platforms/mpc-wallet/ I don’t profess to know too much about these solutions, but they could be a viable alternative.
So before we really start down handing over Development to the community, this I believe should be our first major decision.
Style Guides and Shared Components
Pangolin currently has three web facing applications:
The website is currently written in Svelte, whereas the Exchange and Analytics site is written in React.
My immediate cause for concern is that the React components are duplicated across the two repositories.
This poses a few risks:
- Duplication of code. Don't Repeat Yourself (DRY)
- Any change to one repository will then need to be updated in the other repository to ensure consistency
My proposal is to strip these components into our own “Shared components” library which can then be imported into the Exchange and Analytics repositories.
I’d also like to propose adding Storybook which will help onboard any new designers working on Pangolin.
Code quality
How do we ensure the code quality is up to a certain quality. In terms of code quality, most codebases use Test coverage as a metric to determine how healthy the code is. A common tool is Codecov. My concern is unit tests don’t always catch some of the other common issues that arise in new code. I’ve used SonarQube in the past. This tool is a static code checker and can be used to identify common technical debt and code smells. I would like to have this implemented to ensure we can maintain reports and view historical quality reports on our code base.
Infrastructure
In order for us to have a “beta” Pangolin exchange live on the mainnet we’ll need certain infrastructure pieces in place. Currently these are:
- Hosting of the Exchange website
- Graph deployment
- Potentially a domain
The hosting of the exchange as a static website can be done for free through either Netlify or Cloudflare. Both work really well and anyone of them will suffice.
We’ll need to have a Pangolin subgraph published to the Graph. This will mean we’ll need the community to take ownership of a Graph subgraph that will be officially maintained moving forward.
Features
Now that we’ve talked abit about the Foundational elements, let’s list the categories of new features that we can (potentially) build:
- Staking (both traditional and liquid staking)
- Solving Impermanent Loss (either through Single Sided Exposure and/or through Arbitrage)
- Lending
- NFT’s
- IFO’s, ISO’s and ILO’s
- Derivatives
- Bridges
- Insurance
There’s probably more, but I think that’s a fair bit to cover. What we build will be up to the community to determine priority of. But I’ll go through each category with some of my initial thoughts.
Staking
I see this feature requested a lot on the forums and on Discord. So this may be an early candidate to have developed. It’s important to differentiate between traditional staking and liquid staking.
Traditional staking is what you’re currently seeing on Sushiswap. You lock your funds up and once they’re staked you can’t do anything with them. It’s the same with your AVAX tokens. You choose the length of time you’d like to stake them for and then for that time period you can’t do anything with them.
Liquid staking however means you can stake your tokens, but still then use them for other purposes, such as collateral on Loans. The Avalanche team is currently working on Liquid staking for AVAX, so I believe we’ll start to see more and more movement around this concept over the coming months.
Solving Impermanent Loss
The way I see this is that we could follow some of the other market participants in this area, such as:
Or we could mitigate Impermant Loss by letting Pangolin engage in Arbitrage. I’ve covered some of my thoughts about this here.
Lending
This will allow Pangolin to lend tokens to users after they put up collateral. AAVE is the most successful project offering these services.
The concept is fairly simple. You put up tokens as collateral and can then loan up to a percent of your tokens. So if you have $10,000 in DAI, you could then lend up to 75% of DAI. So you’d be able to lend $7,500 DAI. Your $10,000 is locked up as collateral until you’ve paid back the loan.
Things get slightly more complicated if you’re not using a stablecoin and the price wildly fluctuates. I’m not going to get into that here however.
As a side note, Alchemix is doing some cool stuff in this space with loans that repay themselves over time. Looks very cool.
NFT’s
I’m ambivalent about the current use cases. I see Yetiswap is currently working on this, however it’s not at the top of my priorities. Happy if the community wants it, but DYOR.
IFO’s, ISO’s, ILO’s
What’s with all the damn acronyms ;)
IFO — Initial Farm Offerings
ISO — Initial Subnet Offerings
ILO — Initial Litigation Offerings
IFO
With the help of IFO’s, users can participate in “pre-sales” hosted through DEX’s to get tokens before listing on respective exchanges. Typically the DEX teams will thoroughly vet projects before hosting official IFO’s.
We could use this for Snowball Finance and Sled Finance and any other projects that are launching on Avalanche.
Please see this article for more information:
https://www.bsc.news/post/cryptonomics-initial-farm-offerings-explanied
ISO
Currently we aren’t seeing any subnets coming onto Avalanche, but this will be coming later this year. It would be nice if we could offer the sale of these through Pangolin. This would help us leverage our relationship with Avalanche and would provide real competitive advantage over other DEX’s.
ILO
We’re still waiting for these to start launching on Avalanche, but it would allow us to offer financial instruments no other exchange in the world could offer.
Derivatives
Personally I’d rather create a partnership with Injective Protocol than go through all the work required to launch directives. But I’ll leave it up to the community.
Bridges
I love the idea of bridges and see a lot of value in them. Building a bridge to BSC, means we could theoretically start getting some of their liquidity to move to us.
Insurance
If we’re going to be offering up new smart contracts and innovating in this space, there is a risk we will be hacked. Do we want to build some insurance to cover users that are engaging in the riskier features? I like what Cover protocol is currently doing.
My thoughts
So in terms of what I think we should work on, it relies on some of the current technology available within Avalanche. Considering there is no Chainlink Oracle yet, some of these functionalities won’t be possible.
This, however, doesn’t stop us from setting up some of the groundwork for these pieces of work. For example, I believe ILO’s and ISO’s on Pangolin would be killer features that no other DEX could offer. This would be absolutely massive for our project.
Let me know what your thoughts are? I’d love to hear back from the community.
