PIP03 - Development roadmap

Great news. I’d say firstly bridge then ito👍🏻 Then orhers🤝

Great! A fiat on ramp would be great. I know this is coming for other projects and is necessary to truly meet the masses and grow in the future.

On a separate topic- Regarding IL- it would be nice to have a few options of maybe less rewards but lower risk of IL. Not sure how that would work, but it would really separate pangolin from existing solutions.

Providing liquidity for USDT-DAI or eventually USDT-TUSD and TUSD-DAI would be great. Almost no IL because they don’t vary in price.

Right now there is no stablecoin pool rewarded by PNG. I suggest we add one or more with lower rewards.

1 Like

I support all of the proposed features and agree with others that ITO and bridge integration should take priority.

IMO now Pangolin needs liquidity and visibility. So:

  • Order books: it seems an interesting idea, but to be studied with very low priority. It takes a lot of time and resources. It doesn’t bring liquidity.
  • Bridge. This is a very useful feature that will allow liquidity flow from other markets. Number one priority.
  • Beta pangolin: a must have for testing features.
  • ITO: nice idea but useful in a high liquidity high userbase exchange. Not useful now to bootstrap pangolin. Very low priority.
  • CAP: low priority again because it doesn’t bring liquidity.
2 Likes

Bridge and Order books are both excellent.
Order book is desired immediately to address the current risk of further airdrop token dumps. Didn’t somebody get 5M PNG as indicated by someone’s spreadsheet so if it is that the same individual the order book would do most to mitigate that immediate risk? Second I would integrate the bridge which is useful for whales taking a look. They may stay if they see the order book.Then the testing. ITO and Autonomous Compound proposals both excellent ideas that can be added as strong ideas that can wait as they offer less immediate benefit. ITO is particularly strong and would be more attractive to projects after the other proposals are implemented. Shine that car before your try selling it.

1 Like

I agree with a lot that’s been said here. The best thing we can be doing is to be gaining as much liquidity as possible. The way we attract Liquidity is via these main stakeholders
• Liquidity Providers that are after the PNG rewards
• Liquidity Providers trying to save money on ETH gas fees and higher transaction speed
• Autocompounding platforms

The Bridge will bring in liquidity from other chains, which will be very beneficial for Pangolin. However an oft overlooked player in this space is the autocompounders. Projects like https://beefy.finance and https://snowballs.finance and the newest entrant Penguin finance. These platforms are essential as they allow market entrants to auto compound their yield returns. Encouraging these platforms to co-exist in a mutually beneficial relationship is essential. They bring huge liquidity into Pangolin. If we look at Beefy though, we are losing a lot of liquidity to BSC. Why is that? It’s because BSC offers a lot more tokens which allows crazy yield opportunities. Pangolin offering more tokens on it’s exchange, encourages more autocompounding pairs and brings in the degens.

So while I agree Bridge is one of the key means of gaining access to new markets, ITO allows us to encourage a sub segment of the market that is vitally important for our growth.

2 Likes

Autocompounding is a ruse. It doesn’t matter much if you compound once a week or continuous. And then fees of the autocompunder (20%) will destroy any potential gains, and then some.
Also, I think it bad to support anonymous and potentially fraudulent sites like snowball.

Um, do you understand how compound interest works? It definitely makes a difference how often you compound.

Saying the fees will destroy all gains needs to be backed up with proof. Share the maths and prove that’s the case. I’m highly sceptical this is the case, but if you share the maths I’d be glad to have my opinion changed.

I also don’t think we, as a community, should be throwing words around like fraudulent without proof. Ive met a few of the anon people working on snowball and calling them potentially fraudulent when you have no basis for that is incredibly disrespectful.

You don’t have to support anon Devs and their projects, but plenty of projects with public facing Devs have done plenty of bad things. Look at most banks. Look at most governments.

2 Likes

@hariseldon2 - Fantastic job by you and the devs to get this moving. I’m super impressed that you’ve all made this much progress in thinking and strategy.

All the proposals are excellent although some strike me as obviously more difficult technically and economically, particularly if we are introducing incentive layers to groups such as relayers. While I agree it makes sense to do this, it also introduces new attack vectors which aren’t obvious at first blush.

Regarding the governance proposal - this is a big one for me but first I’d like to see the governance terms - the “Constitution” for Pangolin governance. This needs to include how members are appointed, the voting rules, voting rights, delegations, lock-ups etc etc.

Along those lines, a few preliminary questions:

  • Are we using the same governance model as Compound, including the code?

  • Where is the supporting documentation to support the governance model? Is it Compound’s again?

  • I know this is boring but are any audits being proposed before governance is rolled out? Or are you relying on the audits done for Compound?

  • Are the devs allowing for a proof of concept for governance or are you going straight to decentralised end-state? If there is a phased roll-out, what milestones and time period are the devs proposing?

  • Are you including provision for a failsafe/sandbox as a first stage? Who is managing and supervising this (assuming one is being implemented)?

  • Finally - how are devs being compensated for this amazing value they are adding? We still need to establish a grants program and board, correct?

2 Likes

Look at the math, just google “compound interest formula”. There is virtually no difference between continuous compounding and daily or weekly. The Snowball contract asks an incredible 20% fee, which will surely eat away any advantage, and then some. Only someone who doesn’t understand the math will fall for that.

The main dev behind Snowball has a 2 week old twitter account. How shady is that?

Anyway, there have already been a few rug pulls in defi, and all of them share the following characteristics:

  • new project
  • anonymous devs
  • no thorough independent security analysis of the contracts.

Snowball has all 3. Could it be safe and legit? Yes. But in my view, there is no advantage to their continuous compounding and a whole lot of risk.

Also in my view, a contract like Snowball from anonymous devs shouldn’t be promoted on Pangolin. If something were to happen, guess were the victims will go.

@BobbyC

For most users of the platform, the fee for compounding manually will eat into profits more so than a 20% profit fee (which goes into a governance treasury) . Though at a certain economy of scale point, you’re probably right. It’s also a fork of pickle finance, which has been audited and the founder is pretty active on all AVAX related discord channels.(and seems like a pretty neat fellow)

While I like snowball finance’s team, I understand your overarching point: that PNG official developers should be wary of project endorsements. Voting in developers to vet ITO’s should be a priority the minute it appears that the ITO functionality is about to be implemented.

1 Like

I did the math. What you’re saying is not true unless you’re talking about tiny staking amounts of less than $100.
If the gains are 100% per year, the 20% fee on a $100 stake will cost $34 (I’m assuming they ask a 20% fee on the yearly profit of $172 but if they ask 20% on daily PNG than that is much worse) . At current prices that amounts to 3-4 times claim+swap+stake. So you can do it yourself every 4 months and get pretty much the same end result.
If you stake $200 you’ll make more doing it yourself 6 times a year.

Couple of other things:

  • AVAX labs announced upgrades to AVAX that will lower the costs of transactions.
  • if the gains are smaller than 100%, the effect of the 20% fee will be worse. I don’t think it is likely that yearly gains will turn out higher than 100%.
  • continuous compounding vs daily or weekly is only a small effect. Using the same 100% gains, continuous compounding gives 171.8% gain, daily compounding gives 171.5%, weekly compounding gives 169.3%. The effect really is pretty insignificant for a lot of added risk.
1 Like

You really can tell a lot from a person, by what questions they ask. Thanks for such a reasoned, well thought out response :slight_smile:

Ok, so here’s my brain dump of what I’m thinking:

Bridge

Firstly, the Bridge and relayers. In terms of attack vectors, I see it as, what I’m colloquially calling a Napoleon attack. It’s a Vampire attack like what Sushi did to Uniswap, except it’s cross chain. The way I see it happening, is that a more established DEX goes after the smaller DEX’s and absorbs their Liquidity. Let’s look at DODO

They have over 90% of their liquidity in one pool on Ethereum. If a BSC DEX wanted to absorb that 90 million in Liquidity, they could use their Treasury, drain the Liquidity Pool, use the bridge to push the funds to BSC and then offer crazy $CAKE incentives for anyone on Eth that had LP in that pool.

It would cripple DODO.

Now think about doing that to all the smaller fish in the DEX pond. It’s an interesting thought experiment.

Governance

I haven’t checked up on Compound since about August last year. At that stage they were codifying their proposals. So if the proposal was enacted, the code would then be deployed. I see this as alot of work if proposals don’t pass. As per the Litepaper, the initial Governance model is:

So if we were to implement Compound Autonomous Proposals, it would allow more people to submit proposals.

So currently the circulating supply of PNG is 2,076,770, which at 10% would mean you’d need 207,677 in order to submit a proposal.

The developers are eager to start work so we’re not quite in line with the Litepaper, as currently anyone can submit a Proposal on Snapshot. However, even if those proposals pass, there’s no guarantees they will be enacted. The CAP, would allow that high entry barrier to be reduced.

My thoughts are that having that 10% in place, would reduce some of the noise and improve the quality of proposals. Getting 200K PNG together would require a lot of people to delegate. So I actually really love this idea.

It’s something I probably should have done for this proposal. But I got too excited :wink: There is potential here that the devs form a posse and that community members could delegate to the developer posse.

Audits

This is key for me. Being audited doesn’t mean we’re safe. If you look at this, you can see that plenty of audited protocols are hacked.

There’s a very interesting debate to be had about how do we manage white/black hats. Do we then offer bounties, such as Immunefi?

My thoughts are we should take a hybrid approach. Get audited by a firm and then also add bounties.

It’s important to note that audits will significantly slow down our ability to deploy to production. So we can deploy code to https://beta.pangolin.exchange, but then only after audits are completed, would we then promote to production.

Proof of concept

The Litepaper details how governance will be enacted. That’s why on this forum you’ll see a post from Connor asking if people would like to delegate PNG to him.

This poses a question of whether cult of personality will start to take hold of the community. I know people have talked alot about anon developers, but cult of personality in governance is also a worry for me.

Failsafe/Sandbox

This is why I like Kusama as a concept. I’d love a replicated mainnet that we could play around in, but that’s not currently possible. That’s why the beta.pangolin.exchange will allow us to play with the mainnet and the new features. It also allows real risk, which in my mind, allows more eyes and therefore more potential for exploits to occur. This is the best thing of I can think of currently in this regard, although keen to explore more ideas.

Dev compensation

Currently Connor is employed by Ava Labs but the rest of us are all doing this for free as we love the project. There’s some discussions on this going on in Discord. A lot of people like the idea of bounties. I’ve mentioned using the 0.05% of the Swap fee to fund the dev team. However at this stage, it’s just discussions. I also like the idea of researchers being included in these discussions. Messari does a great intern job and then places the most promising candidates.

There is a very large demand for talented people in crypto and a very limited supply pool. How do we ensure that we attract the best talent? Remuneration is one side, but another side is quality of life. Do we create a launch pad, where we take people interested in getting involved and give them a platform to learn the skills necessary. Like a graduate program. It appears that’s what Avalanche is doing with Cornell university and I like it as a model.

Hope that doesn’t create more questions than answers :slight_smile:

5 Likes

lets complete the bridge integration first and suck the liquidity from other chains…

2 Likes

@ hariseldon2
You talked about a potential liquidity attack on Dodo:
“They have over 90% of their liquidity in one pool on Ethereum. If a BSC DEX wanted to absorb that 90 million in Liquidity, they could use their Treasury, drain the Liquidity Pool, use the bridge to push the funds to BSC and then offer crazy $CAKE incentives for anyone on Eth that had LP in that pool.”

This scenario doesn’t make sense to me because simply buying a huge chunk of the liquidity pool doesn’t empty the pool but it makes the other side more expensive and causes huge slippage for the buyer. In your example, say that BSC starts buying USDT with USDC. At first it would be 1 USDC for 1 USDT but as they start buying more and more at some point they have to pay 1.05 USDC for 1 USDT, then 1.1 USDC for 1 USDT and it goes up and up the more they buy. In the end they would drain the pool of USDT but fill it with much more USDC. Then an arbitrage trader (edit: I wrote market maker by mistake) steps in and starts selling USDT for super cheap USDC, and the pool will go back to were it started and the arbitrage trader would be rich and BSC poor.

1 Like

Hey BobbyC,

Good catch :slight_smile: What you’re describing is the common AMM formula for Uniswap clones x * y = k

Dodo uses what they call PMM (Proactive Market Making).

So in classic AMM’s, the only way to drain the Liquidity Pools would be to entice the Liquidity Providers with incentives. However the newer market making formula’s I’m still trying to understand a bit better.

So I definitely think a lot more thought and discourse needs to happen. It may be completely impossible for PMM, but I haven’t done enough research to know for sure.

Hariseldon2, you are the 0xmaki of Pangolin. Great work!

1 Like

I like all of them. I’m looking forward to the snapshot. Excellent work!

Only a few questions. :wink:

Firstly, thanks for the detailed and considered reply. At this point, each of the topics is going to spin off their own discussion so I’ll try to keep it brief:

Governance

I should have prefaced my comments originally by saying that the Governance I’m referring to is a document in plain language, understandable by humans. One that sets out the objectives for Pangolin as well as the rules and processes. The Litepaper wasn’t intended to do that (for good reason - it’s a tonne of work!)

  • The bullet points from the litepaper are a good start but leave a few open questions for me, principally around lack of time-based measures, scope of Governance and procedure.

  • Currently, Governance only permits changes to “enable several key actions”. Only 2 actions were listed. What changes are prohibited?

  • On time-based factors, I could summarise by saying that I usually test criteria by asking for each one: “starting from when exactly?” “for how long?”

  • To pick one example, one needs 10% of the eligible PNG to submit a proposal. How long does one need to have that 10% stake, and measured from when? Could I arrange a flash loan (costing me nothing) to submit a proposal and then reverse out the loan? On the voting day, I could then repeat the exercise to cast an overwhelming vote. This type of attack could be countered by introducing min wallet/PNG age - say a continuous period of no less than 7 days before the vote. There are actually lots of gotchas in voting and bidding systems, even if the code is rock-solid.

  • I think the initial failsafe I proposed is addressed by having community devs vet proposals in the beginning so that will work for now.

  • Also - was there a decision on quadratic voting or are we keeping it a simple 1 PNG =1 vote?

Notifications.

They’re a big deal in the real world. How are users of Pangolin being notified of (A) votes (B) outcomes and (C) changes that affect trading decisions? There will be thousands of human users who won’t participate in votes but need to be notified on Pangolin that a change is about to occur that may affect their trading decisions (smart contracts and bots are another question). Perhaps the Pangolin front-end can include a short alert with link to more information? I’m trying to address some obvious legal issues around disclosure and minimise information asymmetry without turning Pangolin into a message board.

In closing, we’ll still need to tease out all the sub-rules and procedural matters and document them. That work is important because it will turn people’s minds to the issues, help give clarity to non-technical and business users and stand as a market differentiator as Pangolin grows.

Audits

I agree that having audits on every proposal would be time-consuming and slows things down.

What about targeted audits with agreed thresholds? For example, any proposal changing the core functions or kernels of Pangolin code should be audited. Proposals adjusting UI/UX, pool allocations, and general configuration can proceed without audits. i.e. some sort of standard/normal/emergency split and gradated change model along ITIL lines. Urgh - standards… :slight_smile:

Emergency Changes

Speaking of audits and safety, I haven’t seen anything in regards to emergency changes that can’t wait for proposals, votes and lock-outs. What’s the process involved to urgently update code to protect Pangolin from catastrophic outage/attack? Is there a governance process to safely halt trading and quarantine the platform?

Proof of Concept

The governance model being used is actually a refinement of the litepaper. The litepaper is still very high level and as we drill down, we’ll have to fill in the blanks. I’m reading some of the measures as being short-term fixes, but many aren’t.

Actually, I’m just repeating my earlier comment that governance still needs more detail including a governance roadmap with indicative target dates.