Discussion on transitioning Astroport from cw20 to TokenFactory

General Feedback
1

Hello everyone this is dog,

(Disclaimer: I am a dog, I am a co-founder of Apollo DAO, Apollo DAO owns a sizable stake in Astroport. I am not a developer and will try to explain this in a way that all walks can understand)

I am here to propose a change to Astroport and gather feedback from the contributors, developers and users of the DEX. The change I am bringing up for discussion is to take 1 step back to take 2 steps forward. Currently Astroport uses the cw20 standard which is a token standard that uses smart contracts and adds complexity to the code which makes it harder for other projects (such as Apollo) to integrate with Astro. Out of our own experience as well as being stakeholders, We would like to see Astroport switch to the token factory module open sourced by Osmosis. This would make it easier to add liquidity as well as developer experience for products built on top.

Of course this is not a super easy transition. There would need to be changes to the core code as it would remove the cw20 smart contract logic to replace it with the token factory module. This would essentially “freeze” development on Astroport since such change would need an audit as well as time to integrate. In order for this to work each chain that Astroport is deployed on would need to upgrade to the newest version of TokenFactory module as released by Osmosis a few weeks ago. Also the pools would have to be migrated so the longer this waits the harder/more risk adds up. Much of the Cosmos dev standards are much more leaning towards the TokenFactory so I think that although it would be a slight pause it would allow Astro to free itself of some of the drawbacks of using cw20 in a world where most are using TF.
This would most likely have to be done in stages since there are prerequisite requirements to allow Xastro to function properly and Astro wants to maintain the same code base across all chain deployments.

Token Module makes IBC work better, indexing and front ends are better. The bank module is specifically for this and is better than a bunch of contracts. Here is some of the documentation around TokenFactory Token Factory | Osmosis Docs

To summarize the point of this document is to bring awareness to the possibility of transitioning Astroport from the cw20 Standard to the TokenFactory Module. It will take some time to implement and strategize so more in depth discussions with more people would be great. I am just looking to kick off the discussion so we can go over the pros and cons of this transition. Personally, I think this would be a great upgrade for the long term of the project and should be done sooner rather than later if it is to be done. To start we would need all the chains where astroport is deployed to upgrade to the newest version of token factory in their next upgrades.

1 Like
2

Hey dog! Glad you started the discussion, was writing up something myself, but would rather drop it in here.

I agree that moving to TokenFactory is a good idea as well as the benefits of doing so. I’ve been keeping an eye on TokenFactory for a while but haven’t seriously considered what is needed to make the change due to TokenFactory missing core features needed for Astroport to work everywhere.

Currently, Astroport uses CW20 tokens mainly in the following ways:

  1. The ASTRO token

A standard CW20 token

  1. xASTRO

An extended CW20 token that allows us to check the amount of xASTRO held by an address at a specific block, used in governance

  1. Tokens issued to LPs when providing liquidity (LP Tokens)

Mostly a standard CW20 token, except on Neutron where a variation of xASTRO is sometimes used to track balances for Neutron governance

  1. Wrapping native tokens when used for rewards (see Injective outpost)

I believe this is a standard CW20

Limitations of TokenFactory

The current implementation of TokenFactory does not allow the tracking of balances. Osmosis did some work to make that happen using hooks, but it was recently removed due to “limit the scope and risk of the release” which makes me believe it would make a comeback soon. In this case we’d need to deploy a contract that is called whenever a token is sent to track the balance.

As you mentioned, we’d need all the chains to upgrade to the latest TokenFactory once this feature is ready. We’d also need to convince them to make changes to the SDK’s Bank Module as the hooks functionality is custom to Osmosis and not part of the standard SDK. Most chains run custom SDK versions anyway, so this should be doable.

Migrating ASTRO

This is probably the hardest one to do as it has been IBC’d to different chains. The CW20-ICS20 bridge we currently use could allow us to mint the TokenFactory version instead of returning the CW20 version when you get back to Terra. There is a possibility that all the ASTRO in circulation might never be only the TokenFactory version resulting in permanent fragmentation.

Migrating xASTRO

As mentioned in the limitations, we’d need a tracking contract, but no IBC so that should make it simpler. The transition/migration to a TokenFactory version can also be permissionless and we should be able to migrate everything automatically

Migrating LP tokens

Very much the same as xASTRO, in some cases we’d need the tracking, but mostly we should be able to migrate all holders permissionless-ly without much issue

Migrating the wrapped native token rewards

This touches on the Generator and dual rewards contracts. Both of these have to be updated to support TokenFactory and most likely remove CW20 support - a bit unclear on what is needed here at the moment. It touches many parts of the protocol and will most likely be the most work.

Things we must keep in mind:

  1. How this will affect protocols already integrated with Astroport such as Mars and Neutron
  2. Different chains have different ways of integrating with their TokenFactory, there is no standard at the moment which will lead to chain specific logic being added to the contracts
  3. There is a possibility that this is a one-way change and can’t be undone. To get all the holders of a CW20 token is trivial, while no such functionality exist in the Bank module (without an indexer of sorts). If we can’t query all the holders we can’t migrate them automatically to something else in the future - they’ll need to take manual action that could lead to permanent fragmentation
  4. What do we do if we REALLY want to deploy on a new chain, but they refuse to add TokenFactory?
  5. TokenFactory isn’t a standard yet, if a few months from now a new token issuing method superior to TokenFactory pops up, how would that impact all of this work? (I know it is unlikely, but needs to be considered as this is a one-way change)

This all requires quite a bit of work. I believe it can be achieved with careful planning. If I missed anything, please add.

Edit: This doesn’t affect Astroport pools from accepting CW20 tokens. User’s should be able to create pools containing native, TokenFactory, IBC or CW20 tokens (as it is currently)

Technical References
Osmosis removing TokenFactory hooks
Cosmos SDK hooks for token transfers
Cosmos SDK that doesn’t include required hooks for TokenFactory
Osmosis Cosmos SDK that include required hooks

2 Likes
3

Thanks for making this suggestion.

As @Donovan detailed, it would take quite a bit of work.

I’m not a developer, and I don’t fully understand the benefits to switching to token factory. But I do know there’s lots of things being built for Astroport right now. So if resources were dedicated to this token factory switch, there’d be an opportunity cost.

In my view, the biggest development priorities right now should be: 1) complete the roll-out of PCL, 2) vxASTRO, and 3) integrations with order books.