Now that proof-of-on-chain-work
is a thing, I think it’s time to think about the broader implications this could have and how we can standardise and leverage the unique properties of this “new” and fair(er) approach of distributing tokens.
In the “old” meta, projects trying to conduct a “fair” launch did so by locking the entire supply in a pool with some initial liquidity provided and then burning the LP tokens, making it impossible to rug pull. This is a good start, but it doesn’t solve the problem of insiders and sophisticated users acquiring a majority of the coins.
As soon as the pool has been created, large buys can be placed to buy up large amounts of the coin, sometimes using sniper bots. These are bots constantly scanning the blockchain for new pools, trying to get in as early as possible to extract as much value as possible. Everything revolves around getting in early to extract value from everyone coming in after you.
With the new proof-of-on-chain-work
meta established by bob.fun, the absurdity of getting in early is softened by establishing a well known mechanism, Bitcoin’s Proof-of-Work. By using a similar approach, we ensure that no single player is able to immediately secure a big chunk of the supply, as new tokens are distributed over the courses of time. But this meta does not only benefit investors, but the entire ecosystem by burning ICP to create cycles which are then burned again to (more or less) solve cryptographic puzzles. This boosts the cycle burn rate (already at an ATH) and – as of today – made the ICP deflationary. I don’t need to explain the excitement of having your own Tamagotchi-like miner that you nurture with cycles and send to the mines to do hard work while you drink coffee
We now have the chance to standardise and promote this new distribution mechanism outside of our own ecosystem. Unfortunately, the bob.fun repository has not been open-sourced until now, so for some architectural proposals I use a setup I was working on in the past. It uses different lingo but I think fundamentally it describes a very similar system. It would be great to have the following things:
Launchpad
A launchpad were projects can launch new tokens on the ICP with the aforementioned distribution mechanism. That is, after specifying settings such as the
- maximum supply,
- the halving schedule,
- how frequently the difficulty will be adjusted,
- the block time
- target chain (see “Chain Fusion Minters”)
- general token settings such as logo, ticker, name, transaction costs
- …
This would spawn two canisters, the minter canister and an ICRC-2 Ledger. Instead of creating a new mother node for every new token, we would keep a single, global mother node that is responsible for spawning new miners, upgrading them and keeping a registry of them. This opens up the possibility for participants to “bring your own miner”, that is decide what token they want to mine, similar to how miners in the real world can decide what network they would like to commit their hash power to.
While the mother node is the sole controller on the protocol level, the user currently has some control on the canister level, such as changing the hash rate and the “owner” (that is beneficiary for tokens in case a block has been mined). All we would need to do to enable the above from a miner canister perspective is to give users the ability to set a different minter canister id for their miners. They would fetch all necessary information needed to mine from this canister instead from the mother node, in the current architecture. Upon successfully validating a PoW from a Miner, the Minter would check if the submitter is registered with the Mother Node (this could also be swapped, depending on what is cheaper). Ideally we have some sort of caching in place in the Minter so that we do not need to check if a miner is registered for every PoW submitted. We would also need to investigate how scalable such a single mother node for all tokens is.
Mining Pools
Something that has been discussed multiple times already and even implemented by @skilesare (see here) are decentralised mining pools. Instead of participating in the big lottery as a solo miner, users can contribute hash power to a mining pool. For this, they spawn a miner canister and then set the owner to the pool canister. This flow can be facilitated through the mining pools frontend. You can either spawn a new miner or bring your own miner. The mining pool keeps track who contributed which miners to it’s pool and allows users to remove their miners from the pool to either solo mine or contribute them to a different pool. Of course the pool provider takes a share of the block rewards for his services
Chain Fusion Minters
Why restrict minting tokens to the ICP? With Chain Key Signatures we can “easily” configure a minter to issue tokens on other chains. This could work two ways.
Either by creating an ERC20 contract on Ethereum for example that has the Minter Canister set as the token minting authority. Now whenever a miner submits a valid PoW the minter creates, signs and submits a transaction that would mint the corresponding tokens on the ERC-20 contract to the beneficiary. In this case it’s not entirely clear which address on the Ethereum network would receive the tokens. It would probably help to allow miner owners to specify yet another setting, and that is an explicit beneficiary. We would need to think about how to structure this in the case the minters are able to target many different chains, and that is many different address formats. Maybe it’s sufficient to provide a simple string as the beneficiary and it’s up to the frontend/user to make sure it is valid for the target network they are mining for. With this approach, the minter canister needs to hold a certain balance of the target networks token to be able to subsidise the transaction fees when a new block has been mined, which could be rather expensive in the long run.
Another approach would be to create an ERC20 contract with an extended interface to verify ECDSA or EdDSA signatures against the public key of the minter canister. We then let the minter sign a coupon, that is a Chain Key signed object that contains information about how many tokens should be minted to which address. This coupon is cached by either the miner or the minter and can be retrieved by the owner of the miner that mined the block. The owner of the miner would take this signed object and provide it to smart contract on the target chain by submitting a transaction, e.g. calling a claimTokens
endpoint providing the coupon as call data. The ERC20 contract would then verify the signature on the coupon against the public key of the Minter canister it has stored, and if valid mint the amount of tokens to the beneficiary accordingly.
Especially for this particular use-case – that was brought up by @domwoe in a conversation – I can see how the ICP becomes very attractive as an infrastructure layer for other ecosystems and we’re able to onboard fresh people from other ecosystems to the ICP.
What now?
We should come together as a community and try and standardise the necessary infrastructure needed to enable this and many other use cases and ideas that haven’t been thought of or articulated yet. Please use this topic to share your own ideas, provide feedback and engage!