Delphi's slAMM: Is it suitable for Astroport?

General
1

Delphi Labs has recently introduced a new AMM model called the Shared Liquidity Automated Market Maker (SLAMM). In this new model, there are several key differences from the current Astroport model:

  1. The slAMM model shares its liquidity across various satellite chains. In this model, liquidity can be theoretically made available to the Osmosis, Juno, Neutron, Sei, or even Kujira (if permissioned chains approves such deployment).
  2. The liquidity parameters in each satellite chain is governed by the Hub. Currently, its still undecided if the Hub will be deployed as a Smart Contract on a general purpose chain like Terra, or as its own app-chain, similar to that of Osmosis.
  3. Liquidity providers, similar to that of the current Astroport model, will have a simple UX on their own satellite chain to deposit their liquidity. The protocol will then shift the liquidity wherever its’ needed stripping away the complexities of the backend from the user. As Delphi calls it, “Deposit Once, LP Everywhere”.

Generally, I think the benefits may outweigh the risks of moving into this model, however, I do have some unanswered questions.

  1. What are the risks to the liquidity should there be a IBC relaying issue? Will there be an insurance fund to cover these losses?
  2. Should the Hub starts on its own app-chain, ideally validator fees should be covered by the trading fees alone. However, given that the current trading volume averages around $1.5mil daily, that provides about $1.642mil in annualised fees. If 1/3 of the amount is paid to ASTRO delegators, and validators charge an average 10% commission, that equates to $55k fees to validator. Will there be a change in tokenomics given that Astroport will now need to pay for its own security & this might come out from its own inflation schedule? If yes, how much will the change be from the current tokenomics.
  3. How will the validators vote on governance? The current governance structure for Cosmos is highly ineffective and most validators vote for the sake of voting without understanding the concepts of the proposal.

The purpose of this forum post is to determine if it’s suitable for Astroport to move into a SLAMM model. It’s up to the Astroport community to determine if this is the best path forward. If you’re supportive of this vision in general, but you have reservations on certain parameters, do voice it out here too.

9 Likes
2

The long term aspiration of going cross chain is the right strategy. This is a much better goal than staying put, just on the Terra chain. I would support and encourage Astroport going down the slAMM roadmap.

3 Likes
3

The Delphi paper is very vague on several key points. As a community, we need to reach clarity on these points before putting up any kind of gov prop.

One of the key points: where to place Astroport Hub? I’m in favour of placing it on Neutron, making the existing Astroport instantiation on Terra Astroport satellite #1.

  1. Neutron is going to be secured through ICS from the Cosmos Hub, so it will be the most secure smart contract platform in the Cosmos. Astroport won’t have to pay for or worry about security.

  2. Neutron is going to host Lido, which means lots of LSDs. Before the Terra crash, Lido worked with Astroport, and they were about to deploy a “meta-stableswap pool,” which is a stableswap pool that accounts for the value drift in an LSD-Token pair. So lots of native liquidity will be available on Neutron, and Astroport has an existing relationship with Lido.

Basically, if Neutron is good enough for Lido then it should be good enough for Astroport Hub. Why pay for security when you don’t have to?

(And hopefully Mars outpost #2 is on Neutron!)

3 Likes
4

I support Delphi’s vision to take astroport crosschain by upgrading it to a slAMM model.
They did outline two paths forward: An app-chain or a smart contract probably using Neutron or something similar. My only concern with going the smart contract route is its uncharted territory.
Nevertheless, I think the Delphi team is technically more qualified to make the better decision in achieving their vision and wish them luck moving forward.

2 Likes
5

Those are really good points, @John_Galt . We’ll be having a session with Stefan from Astroport later this week, tune in to ask your questions too.

1 Like
6

Following on with the call with Stefan from Delphi yesterday on Twitter Space, I do think Astroport moving into a SLAMM model has more benefits compared to cons compared to a standalone AMM on a single chain.

Currently, the TVL on Terra stands at $44mil, and Astroport holds 61% of that TVL ($27mil). This highly correlates to the dApps building on Terra, whereas a SLAMM model will expand Astroport’s addressable market to Juno, Kujira (if approved), Neutron, and many more. On top of that, the liquid staking derivatives coming onto Cosmos will enable Astroport to provide the infrastructure to support Cosmos LSDs from Stride, Quicksilver, and others.

However, the new SLAMM architecture should address crucially:

  1. Isolation of liquidity in a satellite chain should the chain be subjected to a malicious attack or being compromised.
  2. Governance should play a large role in determining the chains where the satellites will be deployed and the parameters of the hub. Validators could in theory play the role of validating the chain, building models to predicting volumes required in a chain, and actively participate in determining the parameters of satellite chains. However, these roles may be overwhelming for a small validator for them to make good decisions, hence, sub-governors elected by validators or community can be considered.
  3. The economic model of the Hub situated in its own app chain will require Astroport to pay for its own security, hence, its important that the new architecture includes a re-designed tokenomics of the vx/xASTRO tokomics.

That being said, I do believe that expanding Astroport to a SLAMM model will greatly benefit the Cosmos ecosystem with Astroport’s great UX and phenomenal builders.

1 Like
7

Some more thoughts. I propose Astroport Hub be launched on Neutron. Here’s my argument.

Argument against Astroport Hub as a normal appchain:

1.Astroport Hub as a normal appchain will cost more money, because you have to pay validators. Right now, ASTRO receives 100% of Astroport fees. But if you have validators, they will take a 5-10% commission. Why do this when Neutron provides free security?

2.Astroport Hub as a normal appchain may not have high enough economic security. Astroport Hub will have high TVL, because it will control all liquidity of the satellites. The economic security of the chain, as measured by the total value of all staked ASTRO, will need to be very high. What if TVL is $500MM but staked ASTRO is only worth $300MM? In this example, the cost of corruption is dangerously low.

Will the price of ASTRO scale along with TVL so that the cost of corruption always remains prohibitively high? Maybe, maybe not. Osmosis, another appchain DEX, solved this problem with superfluid staking. And now they’re doing mesh security, too. Why worry about this when Neutron gives the entire strength of Cosmos Security?

(I concede that this point could be solved with mesh security, possibly from Mars Hub).

Argument against Astroport Hub as an appchain secured by ICS:

1.This idea is untenable. The Cosmos Hub would charge a significant about of money for security, severely impacting the price of ASTRO.

Argument in favour of Astroport Hub on Neutron:

1.Neutron is the flagship chain of ICS. The Cosmos Hub has funded the development of this chain, and it is expected to provide a significant justification for ATOM 2.0. This being the case, Neutron will work and will be secure. Plus, if Neutron is good enough for Lido then it should be good enough for Astroport. It’s hard to imagine a world where Neutron isn’t successful.

2.Neutron will have the full security of Cosmos Hub, via ICS. What’s more, this security will be entirely free for Astroport.

3.It’s hard to believe that the configuration of Neutron will somehow be detrimental to Astroport. Doesn’t really matter what the fee token is or how fast the blocks are. Will blockspace on Neutron ever become full and cause fees to increase? Probably not.

I’d like to fully understand why many people think Astroport Hub should be a traditional appchain. What are the concrete benefits of this as opposed to Neutron, and do these benefits warrant the cost of security (borne by ASTRO holders) and the potential issue of ASTRO being insufficient to provide strong enough economic security?

1 Like
8

Fully agreed. SLAMM increases the total addressable market, which will make Astroport more successful.

What do you mean about this enabling Astroport to provide the “infrastructure” for Cosmos LSDs? Do you just mean that it will be easier to IBC LSDs to Astroport? Curious to hear your thoughts on Astroport and Cosmos LSDs. (I work for Stride! :smiley: )

I’ll have to defer to you and other experts on your points 1 and 2. But I do have an opinion on point 3. I’m not convinced an appchain for Astroport Hub is necessary. See my post below. Would love to see the argument for putting Astroport Hub on its own appchain vs on Neutron fully articulated.

9

Oh yes, loving what you guys in Stride are doing. What I meant with infrastructure is that if Stride has a stATOM-ATOM pool, various Cosmos chains will have access to stATOM without the need for users to navigate to Osmosis to get their stATOM. This could certainly bring more utility to stATOM, thus, driving its organic demand on top of all the current partnerships.

2 Likes
10

I completely agree with Max’s take :+1:

11

It is undeniable that the Astroport community on Twitter, Discord & the forums believes that the slAMM model is the future of Astroport. While there are differing opinions on whether Astroport should develop their own app chain or as a SC of an existing Cosmos chain, some community members believe that an on-chain vote will bring a vote of confidence of one over the other.

Would the Astroport core contributors, @stefan , @Bitcoin_Sage would like to chip in on this conversation before an on-chain signal vote is placed in front of the Astroport community?

P.s. I’ll be pushing up an on-chain vote with Gidorah.

12

A signaling proposal makes sense to me Max!

1 Like
14

I just want to emphasize here that this proposal has indeed been properly styled as a social signaling vote and will be taken accordingly–i.e., a passing vote does not mean a slAMM integration of Astroport will definitely be built.

Delphi Labs published the slAMM paper as a piece of independent research about a possible cross-chain AMM design, not specifically tied to Astroport. The discussions here and the proposal are interesting but should not be assumed to lead to any specific course of action by Delphi Labs or other Astroport contributors. Of course, Astroport is a free open-source protocol and anyone may submit a binding proposal to adopt upgrades to it–if they have written the upgrade code!

In most cases, Delphi Labs will not discuss any specific software code it is working on substantially in advance of that code being production-ready. This is to be contrasted with conceptual research / exploratory publications like the slAMM paper.

15

Can we drop the legalese and vote already? No need to pretend. We already know Astroport devs control governance.

I vote YES on this proposal!

1 Like
16

This would be the best business direction for Astroport and it would create a competitive advantage compared to other AMMs. In Astroport’s current state I don’t know why I would prefer it over Osmosis. Yes, it has a very good UI but Osmosis has no tx fees, works smoothly and has more liquidity. It will take some work but I think they can use a lot of experience from Mars. Not going for this model is throwing in your own windows.

1 Like
17

There seems little doubt that that the ‘social signalling’ proposal for support from the community is all thumbs up for Astroport to adopt a SLAMM model.

However there has been quite some ambiguity in messaging from our builder friends recently. Im trying to understand what the next step is.

Following the positive community signalling is the next step then for the builders to “Create a (formal) proposal on an established Dex to modify its architecture from a standalone AMM to a SLAMM… etc”?

If so would we be waiting for another WP on how the mechanics of this modification would occur including any impact on operations?

I do understand the legal context of recent communications from the project leads, but I would suggest that more clarity on where we are in this process is needed. A clear statement of confidence on Astroport’s future would also be particularly beneficial right now in helping clear up some of the misunderstandings Ive read in some Terra community forums.

Meanwhile we have done our best in the Orbital Command discord to help clarify and support understanding of the project.

2 Likes
18

Basically, for there to be a binding proposal, specific code would need to be written and published & then a vote would need to be held regarding any required upgrades to existing deployments like Astroport-on-Terra.

I think people are getting a bit ahead of their skis on this though–slAMM is an awesome concept with some teeth to it, but it’s impossible to know if it will even work without a lot of building & testing etc. Concepts/ideas are one thing, working code that securely implements those concepts/ideas is quite another–especially in cross-chain blockchain environments, where everything is currently very novel, risky and experimental. The Cosmos ecosystem has not yet even fully integrated IBC into a thriving secure ecosystem with decentralized relayers etc.–the kinks are still being worked out. And as discussed in the paper, IBC is a component of slAMM.

FWIW, I have published more general thoughts on how governance should work around social proposals here…As noted, I wouldn’t be too anxious about quorum etc. for signaling votes–strict quorum and majority requirements imo are just for binding on-chain votes. A signaling vote sends a signal even if those thresholds are not met.

3 Likes
19

Hey folks, Spaydh from Neutron.

Quick disclaimer: what follows is only my personal opinion.

My thesis on Astroport when it initially launched was that it was the only credible competitor to Osmosis as the/one of the main DEXes for the Interchain, and one of its interfaces to the rest of the industry (through shuttle, wormhole, etc.). While the crash obviously weakened this thesis and contributed to drying up the liquidity, I remain extremely bullish on Astroport, its community, development team, and the vision of a rekindled trading experience across chains.

There are obvious challenges associated with building a slAMM on top of Astroport, but I do believe that this is the type of architecture we should be working towards: liquidity and volume are no longer siloed on Terra, and if Astroport wants to capture a meaningful share of the market, it will not only need to expand across the Interchain and the rest of the industry, but also gain a competitive advantage to overtake market share from the incumbent AMMs.

I’m glad to see @John_Galt and @MaxCallisto have been discussing Neutron as a potential home for Astroport’s future Hub. I think they’ve accurately discussed the trade-offs involved in the choice between Neutron and an appchain:

The cons of building on Neutron:

  • Shared blockspace implies there may be times of congestion, degrading UX.
  • Less direct control over the low level stack. Launching your own appchain means full control over the stack. For the slAMM, this would mean being able to schedule regular tasks through Begin/Endblockers or the ability to have validators run predictive algorithms for example.

The pros of building on Neutron:

  • Higher PoS security, making the AstroHub safer
  • Lower cost of security, making the slAMM more profitable
  • Reduced engineering overhead: most of the infrastructure has already been built by our team, enabling Astroport to focus on building the best DEX.
  • Composability with other primitives (Lido’s derivatives, native USDC,…)
  • Path towards predictable blockspace through application-specific rollups
  • Faster cross-chain interoperability between dApps on Neutron, its L2s, the Cosmos Hub and ICS chains thanks to a “lite” implementation of IBC enabled by the shared validator set
  • Technical requirements can be met by specific implementations that can serve Neutron’s entire ecosystem of dApps: for example, we are working on a module that would allow smart-contracts to access Begin/EndBlockers to run regular tasks without relying on 3rd party bot networks. A parametrizable prediction market system could be used to allocate the slAMM’s liquidity by rewarding accurate predictions and punishing bad ones economically, and without the centralizing pressure that running this game at the validator level would create.
  • Baseline activity through Neutron’s fee handling: we intend to eventually enable fees to be paid in any currency, and handle the denominations under the hood. These swaps could be made through Astroport’s pools if it indeed becomes Neutron’s main DEX, providing stable revenue to Astro LPs and holders.
  • Privileged access to the Cosmos Hub‘s network effects and liquidity, especially in the advent of ATOM 2.0

One last thing perhaps worth mentioning is that we’re researching and developing “Voting Vaults” to allow DeFi users to participate in Neutron’s governance in a capital efficient way. The basic implementation would look akin to Osmosis’s superfluid staking, e.g the ability to stake NTRN-XXXX LP tokens to obtain voting power, but more flexible: it could eventually accept receipt token from NTRN deposited in Mars and other types of DeFi positions, and attribute voting power to them. This could potentially allow LPs to get triple incentives + voting power on strategic positions.

From Neutron’s perspective, working with Astroport is also a win: as a DeFi platform, it will need a set of premier DeFi primitives:

  • a DEX (trading) → Astroport?,
  • a Money Market (leverage) → Mars?,
  • good Liquid Staking (yield bearing assets) → Lido,
  • stablecoin(s) → initially native USDC, but I’ll be looking forward to robust, scalable and decentralized stablecoins.

Astroport has the potential to be one of these premier lego blocks, and it seems to me that interests are well aligned: Making Astroport the most successful DEX in Cosmos would validate both Neutron and the slAMM theses.

2 Likes
20

Thanks for jumping into the conversation!

You might be conflating the Astroport Hub and an Astroport Satellite. The Hub is the administrative centre of Astroport; there’s no trading on the Hub. Satellites, on the other hand, are deployed as smart contracts on other L1 blockchains, and that’s where the trading takes place. The Hub could be its own L1, or it could be hosted on another L1. If there were an Astroport satellite on Neutron but not the Hub itself, Astroport could still benefit from many of the things you point out.

But anyway, the inescapable advantage to having the Hub on another L1 as opposed to its own L1 is that the Hub wouldn’t have to pay for security. That’s the big thing. Why pay validators and bother with chain infrastructure when you don’t have to?

For that reason alone, Neutron would be an excellent place for the Astroport Hub. Then again, since this conversation began the situation on Terra has improved considerably. Maybe putting the Hub on Terra would be an equally good idea. Incidentally, according to Jose from Delphi in this recent interview, Astroport contributors are still thinking about whether the Hub should be its own L1 or be hosted on existing L1. They haven’t decided what’s best yet.

But going back to Neutron, it would be amazing if at least an Astroport satellite could be launched there. I agree with all your arguments in favour of doing so. Currently Astroport is being tested on Sei and Injective, and Neutron would be a welcome addition to the growing Astroport network.

I would encourage you to begin / continue business development with the Astroport community and with Delphi. Drop by the Discord regularly, and post on the forums from time to time. Make people aware of the huge advantages to having at least an Astroport satellite on Neutron (and maybe the Hub itself, too). Show people that Neutron is open to an Astroport satellite. I personally am completely in favour of the idea (:

2 Likes
21

Hey @John_Galt, I understand the difference between the satellites and hub. I’ll admit I didn’t clearly differentiate between both in my writing, for the simple reason that it seems a no brainer to me that Astroport would deploy a satellite anyway, just like Osmosis and Duality will: if there is a market on Neutron, why not capture a share of it?

From Neutron’s perspective, this is also a no brainer: as a permissionless platform, we have neither the intention nor the means to deter Astroport from launching a satellite. We’ll be happy to see Astroport grow, whichever way Labs and the community chooses to take Astroport :grin:

As a result, the real question is whether the Hub should be launched on Neutron too. That is the vision I described, one where there is both a satellite and the hub on Neutron. It has the security/cost advantage you mentioned, as well as reduced overhead, since most of the cross-chain infrastructure required for the Hub to be able to coordinate its satellites has already been implemented.

This is not the case on Terra, Juno, Sei nor Injective unfortunately, as even with ICA enabled, smart-contracts would still not have an interface to interact with the module, and still no access to cross-chain queries. Beyond security, these are some of the problems that Neutron solves: it expands ICA to not only provide smart-contracts the ability to manage accounts and execute transactions, but also track execution status and trigger callbacks, via a simple interface. In Astroport’s context, this is needed for the hub to govern satellites, for example.

In any case, I trust Labs and the community will make the best decision for Astroport. Since Neutron is one of the options, I thought it would be useful to be part of the conversation and make sure there could be an open channel to discuss pro-and-cons so that the best decision could emerge, which is why I’m here :slightly_smiling_face:

1 Like