# Juno CW20 -> TokenFactory

## Background

- Juno v12 contains a permission-less tokenfactory
- cost 1 Juno to make a Denom, governance controlled
- going on testnet early/mid December, mainnet launch early/mid January

## Considerations

- With this launching, new daos/devs will want to use the tokenfactory
- This means we need to get ahead on migrating to the new factory to improve dev & legacy code experience

## Reasons to migrate

- Native denom is easier in wasm (info.amount instead of Cw20 hooks, can just use --amount in CLI / keplr)
- Sending via CLI is easier with `junod tx bank send key addr 100factory/addr/name`
- MUCH better/more efficient query via x/bank
- easier to Transact natively via CLI without wasm executing msgs
- Auto shows up on Mintscan & keplr
- Easier for snapshots/airdrops (via `junod export`, rather than paginated CW20 query)
- x/bank module is more tested [every chain] than CW20 [20 chains]
- only other chain with token factory = osmosis and is permission wasm. Doesn't get the full benefit

# Juno working Issue
- https://github.com/CosmosContracts/juno/issues/334

---

# Migration of Liquid Tokens

### 1) Airdrop Style
- https://github.com/Reecepbcups/cw20-to-native
- Not ideal for most, but is _A_ solution
- This script queries the CW20s on the network, the holders, and the amounts
- Then it produces a file of those as the new denomination to mint. (can query from other chains easily)
- Contract developers end support for using CW20 on the old network and ensure only the new factory is used. makes the old CW20 worthless
- Could launch solution #2 on that chain if it support permissionless cosmwasm
- Needs:
- make both scripts in the same language. (1 bash one python right now)

### 2) CW20-to-tokenfactory
- https://github.com/Reecepbcups/cw20-to-tokenfactory
- `cw20_burn_balance` is a more ideal solution IMO
- Developer launches the contract & funds it with some of the new factory tokens
- user deposits their CW20 into the contract
- The contract sends a 1-1 amount of the native tokens it has to the user who interacted
- (There is also an option to make this contract the admin/minter if you would like)
- The contract burns the CW20 it was sent
- If you need multiple contracts to mint, use CW1->tokenfactory mint

- Needs:
- UI front end, clean up the contract, ensure there are no vulnerabilities
- DAODAO may integrate this in their frontend after v2 launch

### 3) CW20 migration conrtact
- Requires you/DAODAO to be the admin of said contract
- Create the tokenfactory denom, and deposit amount = the total CW20s in your contract
- Write a CW20 contract which on migrate, burns all users tokens and bank sends them the factory token. If not enough bank balance, fail the migrate
- Issue
- DAODAO well now it has a bunch of tokens for staking tokens, so we have to migrate the staking contract, etc. 2nd hand effects. migrate Cw20 & staking contract & users dont have to touch

### 4) IBC'ed CW20s (terra2 for example, YFoundry)
- when you IBC CW20 -> another chian, it makes a native denom. So may have to do the burn contract on the native chain (osmosis/terra2) since x/bank can't burn standard unless we sent to null addr

# DAODAO (Staked) Tokens
- **CHANGE DEFAULTS FROM CW20 TO TOKENFACTORY AS SOON AS POSSIBLE IN UI**
- get daodao to native tokens
- Migrating a DAO's voting right tokens to the new native token
- Ekez, Jake, Reece
- Migration: pre-fill the contract funds with the factory/ denom, migrate then convert the bonded tokens -> the new factory denom

#### 1) CW20 staked migrate auto. Similar to #3 above
- check total staked cw20, ensure the dao has the same amount of current factory/ tokens
- possible to migrate cw20 stake -> native (burn cw20-> mint/give the balance to the new factory/ which are in the daos funds)

#### 2) Vote module Middleware (Ekez):
- IMO this feels too half way solution
- vote module for DAOs which are cw20s, make prop to set VP based on number of staked CW20 + number of native tokens (KLEO may have done?).
- Then, UI when someone is staking is always native
UI: if someone has liquid CW20, we give them popup to convert to TFactory denom
- existing stakers work, new stakers use tokenfactory
- when they unstake, the UI will prompt to get in native factory from the CW20

#### 3) CW20 Wrapper
- CW20 native token wrapper, migrate CW20 contract. Move all the tokens over to the new native, burn old
- backwards compatable, native still managed by cw20 contract functions. best of both, but still a half way solution

---

# AMM Pools

- Migration of AMM Liquidity Pools
Consensus right now is just to require the users to unbond, and rebond the new tokens.
Not sure there is much we can do. Is a one-time 14-day hit which sucks
Protocols may want to increase native fee pay/airdrop some for the rewards downtime

pain for a few months, but best feature in the future

rename LP to NetaCW20-Osmo or something?