Token Factory Module

[byte-bandit]

Tokens native to Paloma

• Introduce a fresh token factory module which (in theory) allows anyone to create, mint and burn tokens, with most features disabled
• New tokens may be created by anyone
• Tokens can only be minted by the admin of the token (by default, the creator of a token is the admin)
• Tokens can only be burned by the admin of the token
• All data is respected for genesis import/export
• Skyway registrations against user tokens do not require governance
• MAKE SURE that the GRAIN mapping cannot be touched though
• Creating a token costs 10 GRAIN

Tokens for bridging

• A new token for bridging can only be created by governance vote
• Owner of a bridged token will be the skyway module account
• All data is respected for genesis import/export

Important: Bridging a token requires considerable effort (votes + one smart contract on remote chains) per token, so best to keep these to established tokens like WETH. User tokens should live only on Paloma.

[taariq]

@byte-bandit Thanks for this a few notes:

1. We won't need to worry about spam. We actually want to allow anyone to create these new tokens as needed as Paloma's Got Talent will let anyone create their own talent token.
2. Tokens can be minted by anyone as long as they are not minting the same denom
3. Tokens can be burned by anyone as long as they are not burning tokens not in their possession
4. Kujira has a token denom module created that looks like it will prove helpful: https://github.com/Team-Kujira/core/tree/690a0dece9372993178deb467e2f0ae49d0733ce/x/denom

[byte-bandit]

@taariq

Roger that. Take a look at the updated requirements I put in the ticket description and let me know whether this makes sense to you.

[taariq]

@byte-bandit Thanks for the update. We really want to remove all friction from creating tokens and bridging so they are fast and permisionless as possible. For example, bridging Paloma GRAINs from Base to Solana via wormhole takes only 10 minutes. No need for governance.

iI we can get a special type of vote that's very fast say 15 minute vote for registration, instead of 24 hours as our current fastest, then we can keep the voting mechanism and still speed up governance just for token registration.

[taariq]

@byte-bandit New README from Osmosis version of the denom module: https://github.com/osmosis-labs/osmosis/blob/main/x/tokenfactory/README.md. Kujira was the WASM bindings which we want for using via Cosmwasm. Also, Epic for this is now here: https://www.notion.so/volumefi/EPIC-12-13-24-Paloma-Token-Denoms-for-Paloma-s-Got-Talent-157e002bb6218089b233fc24b1f1d984

[byte-bandit]

@taariq After our conversation from yesterday, this is my current understanding of how things might be possible with Paloma at the moment:

1. SPL token ACOIN is generated (protocol doesn't care how) on Solana
2. ERC20 token ACOIN is created on EVM chains (at the moment, manually. In the future, possibly automated)
3. SPL ACOIN can be bridged to the ERC20 equivalent on EVM chains using wormhole

So far, the protocol is completely unaffected by any of this. Continuing:

4. User creates a new denom acoin on paloma
5. User registers denom acoin against ERC20 token addresses on EVM chains
6. Using the skyway bridge, users can now bridge the ERC20 ACOIN to Paloma
7. Users can trade tokens on Paloma using smart contracts
8. Using the skyway bridge, users can bridge their tokens back to EVM chains

This is where the protocl stops becoming involved again. But for sake of completeness:

10. Using wormwhole (or anything else), users can bridge the ERC20 token back to the original SPL token on Solana

---

Can you confirm this is how you want to approach this?

[taariq]

Closing as shipped with palomachain#1318