Request for Project - Programmatic Token Presales

[handsdiff]

If you're interested in the below, I highly recommend you launch the project open source, with a token, on Z Combinator. Please reach out to me on Telegram or Discord if you want to chat more. My @ on both is handsdiff. If you want to take the idea and not use Z Combinator at all, that's fine too. For what it's worth, I would consider that an optimization of first order, rather than long term, value creation and accrual.

---

Motivation

There has been an overwhelming amount written about optimal token launch designs, and the space is still not uniformly solved. Even a small dent in this vertical, pump.fun, is a multi billion dollar protocol. The problems I see today largely result from the bonding curve -> AMM design that pump popularized, more specifically around the ordering of participants in the bonding curve. The canonical way people describe this problem is 'snipers'. What it actually means is unaligned participants who have no plans to grow the token value getting early, lower prices, while aligned participants who want to bagwork get later, higher prices. Ideally, the person who is going to hold the longest and contribute the most gets in at the best price.

A gap I can't help but notice is in the ability to whitelist wallets and their capped amounts for the sale of a token on a bonding curve. We are just starting to see this with the manual implementations of Z Combinator (see the launch for $PERC) and the dev.fun IPOs on pump. Simply, whitelisted participants send funds to an escrow wallet, that wallet performs the first buy when the token is launched onchain, and presale participants can claim their purchased tokens over time, with everyone sharing an average price.

Functionally, this is identical to a fixed price ICO where some portion of funds go to a treasury and some go to a liquidity pool. The only difference is the implementation. Regardless, why isn't there an out of the box solution for this?

Solution

All APIs used for the $PERC presale on Z Combinator are already written and live, in ui/api-server.ts. All that is needed are tweaks added to make the system a bit more usable for others. Specifically:

1. Add documentation for the endpoints and how to use them to the docs/ folder.
2. Instead of whitelisting purely based on a snapshot of the holders of other tokens, also allow whitelisting to occur given an input list of wallets with capped investment amounts. The holder snapshot was a simple way of bootstrapping a list of aligned wallets with sale caps.
3. Add the ability to perform the same presale on any launchpad, not just Z Combinator. The technology itself is launchpad agnostic and there is clearly demand for it.

If you want to launch a separate project for it, extract our code into your code, and edit our code to call your code. We encourage this!

Future

Presales, and token launches in general, are an extremely lucrative space. That also means that it's an extremely crowded space. The Z Combinator team will most likely execute on this issue if no one else picks it up, since some of our design partners require it. Because of its urgency, good execution here will be heavily rewarded.

Update 10/31

I (hands) am going to actively work on this (and probably launch it as an independent project). Three broad categories need to be mentally coalesced: the existing code, the market desire, and the design space. [https://vitalik.eth.limo/general/2017/06/09/sales.html]

At a high level, there is nowhere for developers who want to actually access 'ICM' to actually do it. ICM = internet capital markets = onchain, unregulated capital formation. If I'm a dev and I want to raise money for my project by selling tokens, where do I go? Believe imploded. Pump doesn't support fundraising. Coinlist is nonexistent. MetaDAO is restrictive. PinkSale is dead. Soar isn't live. Star failed its last 4 launches. I'm not aware that Z Combinator offers presales.

One form factor solution, described above but with different motivations, is a programmatic way to open a presale, collect funds, and sell the token to investors, having the token trading after. This simply does not exist. The question now is what are the requirements for a good token sale. Unfortunately, there are no good answers. The Vitalik blog linked above better explains this, but the best you can do are tradeoffs.

We can start from our existing code. It initializes an escrow wallet, allowing whitelisted wallets to deposit funds and track their contributions. The developer can decide when they want the presale to close which then takes the escrow funds, trades it for the native token, initializes a liquidity pool, and allows investors to claim their purchased tokens over time.

The issues with the existing code are (1) the process for fetching whitelisted token holders is manual, (2) the bonding curve migration is manual, (3) its probably suboptimal for presale participants to be up on their allocation when the market opens, or maybe the multiple presale participants are up should be configurable, since this is what teams seem to actually want, (4) presale contributions are tracked in db, not read from onchain, and so fall out of sync, (5) presale contributions are not double checked against the whitelist and refunded after the fact as needed.

The drawbacks of this approach are (1) our core value prop is not fundraising, (2) this product offers no distribution, which is one of the main value props of existing launchpads that a builder would consider, (3) whitelisting decreases raise amount, (4) single token sales are suboptimal as a broad class of solutions to begin with.

For one of our initial customers, the desire is to have a programmatic presale API to integrate into their frontend. The outstanding question here is: is it possible to have presale participants not up at all on their allocation when the token launches on an AMM with the existing codebase?

Downstream outstanding questions are how to best build a continuous funding mechanism where sales occur daily and what properties those sales would have, how privacy comes into play via fresh wallet escrows for each deposit, etc