On October 10th, 2017, we launched the AirSwap Token (AST). While many Ethereum-based token sales are driven entirely by smart contracts, we did things differently. AirSwap itself is an Ethereum-based decentralized global marketplace, and a token purchase could be a trade on the marketplace. Launching the token this way gave us several benefits, but also meant that we had to build and operate our core platform to support the launch itself.

Our token launcher is an implementation of the Swap Peer Protocol that provides each buyer an order, which is in turn submitted to our exchange contract on the Ethereum blockchain. The exchange contract, which you can see deployed via Etherscan and source code on GitHub, is also an implementation smart contract found in the Swap whitepaper.

It’s been shown time and time again that performing token launches through crowd sale contracts creates pressure and congestion on the Ethereum network. We hoped to relieve this during the sale by lifting the token purchase flow off of the blockchain and onto the token launcher. Additionally, we guaranteed each buyer in the main sale an opportunity to purchase tokens over the course of 23 hours, demand was smoothed over that time. With an order in hand, buyers could then complete their purchase at their leisure using an Ethereum browser extension like MetaMask.

We were able to harden core platform technology and immediately operate the platform at scale, which did well. The team worked to minimize latency while providing 100% uptime for persistent connections, even during code upgrades. This meant redundancy, fault tolerance, and active monitoring. During the 48 hours of the public and private sales, we deployed frontend code 4 times and hot upgrades to the backend 3 times. Our continuous integration (CI) process was designed and scripted to allow us to deploy confidently.

Preparation

To set up for the sale, we transferred 45.2M AST to our hot wallet, the private key to which was very well protected. Prior to each sale, we approved the exchange contract to only transfer the amount of that sale so there was no possibility of selling beyond the per-sale amount.

Approaching the main sale, we iterated through a sequence of load, test, fix, and deploy an average of once per hour. Our work the day before launch centered around edge case checking and fixing minor issues. We ran a core suite of automated tests against our code that we had been developing for months. We distributed load testing through Tsung and AWS, hammering our boxes with 50 connection requests per second. This was thought to be a ridiculously high number. We later learned differently.

The Main Sale

Our main sale enforced a maximum (cap) for individual order size based on the number of participants. The total number of tokens sold in the main sale was 42M AST, among 12,719 white listed registrants, making for a 3,300 AST individual cap. The sale was to be run over 23 hours from 10:10:10am to 9am the next morning, so every participant would have the opportunity to purchase at their convenience.

The morning of the launch, we were up early for final preparations. We deployed the latest frontend code and used our beta environment to conduct multiple complete end-to-end purchases on multiple computers using multiple wallets. We ran the beta tester sale, and our betas were supportive and patient as we finalized the deployment. About 30 minutes prior the sale, we began reducing the TTL on our DNS records in preparation for a DNS cutover to our production token launcher code. Prior to the sale opening, buyers would see a countdown on the UI, which would switch to the purchase flow once the sale opened.