SlideShare una empresa de Scribd logo
1 de 37
Descargar para leer sin conexión
ICO protocols and implementations
Ivan Kamakin
AMSTERDAM | MAY 8-9, 2018
2
Prerequisites
• Beginner-level Solidity (should have been covered in a previous talk)
• Should generally know how blockchain and Ethereum work
• Beginner-level economics and game theory
3
Quick notes about implementations
• No token-specific logic
• There’s going to be some self-explanatory modifiers, like
onlyOwner – they’re taken from OpenZeppelin reference
implementations
• The examples are simplistic and purposefully feature-poor
4
Motivation
• DLT is the most multi-faceted state-of-the-art technology
• In blockchain or DLT economics and tech are inseparable
• It’s your job too ensure that an ICO accomplishes the goals of
the business
• It’s also your job to ensure it doesn’t go up in flames
5
Ancient history
• Mastercoin (2013, now called OMNI) is generally believed to be
the first ICO – an uncapped sale
• Ethereum – 2014 – also uncapped
• Not very sophisticated models due to limitations in
instruments
• A lot of ICOs accepted contributions in different coins – not
done anymore due to arbitrage risk
6
Really easy to implement
Uncapped sales
IMintableToken token;
uint public startBlock;
uint public endBlock;
uint public exchangeRate;
uint public weiRaised = 0;
Contract attributes
modifier onlyWhenOngoing() {
require(block.number < endBlock && block.number >= startBlock);
_;
}
Modifier to only receive payments only when the ICO is running
7
Really easy to implement
Uncapped sales
function buyTokens(address buyer)
public
payable
whenNotPaused
onlyWhenOngoing
{
require(buyer != 0x0);
require(msg.value != 0);
uint boughtTokens = getValueWithBonus(exchangeRate*msg.value);
weiRaised += msg.value;
token.mint(buyer, boughtTokens);
}
function getValueWithBonus(uint value) private view returns (uint) {
// Specific bonus calcualtion rules here.
return value;
}
Bonus calculation
A function to buy tokens
constructor(
uint _startBlock,
uint _exchangeRate,
uint duration,
address tokenAddress
)
public
{
owner = msg.sender;
startBlock = _startBlock;
endBlock = _startBlock + duration;
exchangeRate = _exchangeRate;
token = IMintableToken(tokenAddress);
}
Contract constructor
8
Really easy to implement
Uncapped sales
Fallback
A function to withdraw Ether from the contract
function() public payable {
buyTokens(msg.sender);
}
function withdrawFunds(address withdrawAddress, uint amount)
public
onlyOwner
{
require(withdrawAddress != 0x0);
require(amount != 0);
withdrawAddress.transfer(amount);
}
9
Uncapped sales
• Simple model – just publish an address/contract and receive
money
• Unlimited participation
But:
• Uncertainty of valuation
10
Uncapped sales
Theoretical Nash equilibrium
Empirical evidence
Indirectly lead to congestion
Picture: Ethereum token sale stats by Vitalik Buterin
11
Uncapped sales
Examples
• Mastercoin, Ethereum, Antshares (now NEO) – almost every ICO
before 2016
• The DAO
• NXT – fixed token supply, but uncapped – we will see iterations
on this model later
• Tezos – the more recent example
OpenZeppelin’s standard crowdsale reference implementation is
an uncapped sale
12
Capped sales
• Instead of accepting tokens from anybody, set a maximal
capitalization
• Stop the sale upon reaching the cap
• You can even set the cap in fiat if you have an oracle
• Tricky to implement in Bitcoin, as you have no direct way to
stop accepting payments – that’s why it wasn’t really popular
until Ethereum
13
Really easy to implement
Capped sales
Contract attributes
IMintableToken token;
uint public maxCap;
uint public exchangeRate;
uint public weiRaised = 0;
function buyTokens(address buyer) public payable whenNotPaused {
require(buyer != 0x0);
require(msg.value != 0);
require(weiRaised + msg.value <= maxCap);
uint boughtTokens = getValueWithBonus(exchangeRate*msg.value);
weiRaised += msg.value;
token.mint(buyer, boughtTokens);
}
One new check compared to uncapped
14
Really easy to implement
Capped sales
Constructor
constructor(
uint _maxCap,
uint _exchangeRate,
address tokenAddress
)
public
{
owner = msg.sender;
maxCap = _maxCap;
exchangeRate = _exchangeRate;
token = IMintableToken(tokenAddress);
}
Those are all the changes
15
Capped sales
• Also very simple – the only new variable is the hardcap
• Valuation is strictly defined
• Incentivizes to enter early
But:
• Uncertainty of participation
• Causes network congestion and “fee wars” (see BAT)
16
Two sides of a really bad coin
Uncapped sales
• Not really a good way to
attract reasonable investors
• Can behave weirdly from
game-theoretic point-of-view
• Will attract a lot of attention
from adversaries if the final
valuation is very big
• May cause regulatory
problems
Capped sales
• Incentivizes gold-rush
mentality
• Easy for “whales” to push
out other investors
• Network congestion
17
Reverse Dutch Auction
• Capped crowdsale
• The purchasing power of investors’ contributions grows over
time (which means the total valuation falls over time)
• If an investor buys at some point in time, then his percentage
of tokens at the end of the sale will not be lower than at that
point
18
Reverse Dutch Auction
Contract attributes
IMintableToken token;
uint public maxCap;
uint public startBlock;
uint public endBlock;
uint public bpPerBlock;
uint public weiRaised = 0;
mapping(address => uint) bids;
modifier onlyWhenOngoing() {
require(block.number < endBlock && block.number >= startBlock);
_;
}
modifier onlyAfterSale() {
require(block.number >= endBlock);
_;
}
Modifiers
19
Reverse Dutch Auction
Constructor
constructor(
uint _maxCap,
uint _startBlock,
uint duration,
address tokenAddress
)
public
{
owner = msg.sender;
maxCap = _maxCap;
startBlock = _startBlock;
endBlock = _startBlock + duration;
token = IMintableToken(tokenAddress);
}
function makeBid(address _bidder) public payable
onlyWhenOngoing {
require(_bidder != 0x0);
require(msg.value != 0);
require(weiRaised + msg.value <= maxCap);
bids[_bidder] = msg.value;
weiRaised += msg.value;
if (weiRaised == maxCap) {
endBlock = block.number + 1;
}
}
A function to place a bid in the auction
20
Reverse Dutch Auction
A function for the bidder to withdraw their tokens
function withdrawFunds(address withdrawAddress, uint amount)
public
onlyAfterSale
onlyOwner
{
require(withdrawAddress != 0x0);
require(amount != 0);
withdrawAddress.transfer(amount);
}
A function to withdraw collected Ether
function receiveTokens() public onlyAfterSale {
require(bids[msg.sender] != 0);
uint saleDuration = endBlock - startBlock;
uint soldSupply = (token.totalSupply()*bpPerBlock*saleDuration)/10**5;
uint bidderFraction = (10**18 * bids[msg.sender]) / weiRaised;
uint bidderTokens = (bidderFraction*soldSupply)/10**18;
token.mint(msg.sender, bidderTokens);
bids[msg.sender] = 0;
}
21
Reverse Dutch Auction
Picture: Gnosis sale model by Gnosis Team
22
Reverse Dutch Auction
• The model doesn’t have uncertainty of valuation, as it is
essentially a capped sale
• Doesn’t solve uncertainty of participation directly, but
circumvents it
• More resistant to “whales” because the remaining part of
supply can be used in clever ways
23
Reverse Dutch Auction
Important example – Gnosis sale
≈0.33
≈0.05
24
Other mechanisms
• Proportional refund
• Hidden caps
• Multi-round sales
• Uncapped with fixed supply
These mechanisms can be used in capped and uncapped sales
and Dutch Auctions and combined among each other.
25
Proportional refund
• If the total amount raised is 𝑝 and the hardcap is 𝑞 ≤ 𝑝, then
𝑝−𝑞
𝑝
is refunded to each contributor.
• A kind of a balancing act between uncertainties of
participation and valuation
• It would be good to research investor preferences (mainly
their marginal utility respective to token percentage) before
using this mechanism
• Works great in multi-round sales
26
Hidden caps
• As in blockchain all data is open we will need an additional
transaction – the hidden cap reveal may get stuck due to this
• Weird on its own, as it removes certainty of valuation without
adding anything
• However, could be a great “whale” deterrent if used smartly
27
Multi-round sales
• Work great with other mechanisms, as we’ve seen
• Allow to give more control over the funding to investors
28
Uncapped with fixed supply
• The same thing as proportional refund, only without the
refund
• Isn’t particularly useful, aside from an interesting multi-round
model
29
State-of-the-art
• Interactive Coin Offerings by Teutsch, Buterin, Brown (2017)
• Direct-to-Market Dutch Auction by Darryl Morris (2017)
• DAICO by Buterin (2018)
30
Interactive Coin Offerings
• An uncapped sale
• Contributors can place bids and withdraw them until a certain
moment called “withdrawal lock”
• A fraction of the bid that cannot be withdrawn grows with
time
• Each contributor also submits a valuation cap with their bid
• After the withdrawal lock the contract automatically removes
the bids with caps exceeded by the current valuation at each
time step
31
Interactive coin offerings
• Valuation monotonically increases
• Very resistant to attacks and stretched out in time
• It neutralizes uncertainty of valuation by allowing contributors
to interact and collaboratively arrive to optimal valuation, and
a contributor can opt-out from unsatisfactory valuation
However: it is tough to implement
32
DTM Dutch Auction
• A Dutch Auction sale, but it proceeds a bit differently
• Instead of raising the percentage sold, the total amount of
tokens is divided into lots
• Lots are made available for purchase sequentially, with each
next lot costing a fraction of previous one
• This proceeds until all the lots are released
• However, unsold lots remain on the order book
33
DTM Dutch Auction
• Creates a possibility for secondary-market funding
• Could induce some gold-rush mentality after market-price
discovery, but this could be neutralized with proportional
refund for each lot
34
DAICO
• Funds are raised with any ICO model
• However, they cannot be used by the team immediately
• The investors control how much funds the team can withdraw
in a block
• They can vote to either raise this amount or destroy the
contract and proportionally refund the remaining Ether to
contributors
35
DAICO
• A model is easy to understand
• Gives the investors ability to control funding, removing a lot of
concerns on valuation
• However, the crowdsale should probably be “whale”-resistant
• The voting system has to be carefully designed
36
That’s a wrap
Github repository:
https://github.com/Van0k/CodemotionContractExampl
es
Contract examples and links are all there
My contacts:
Email: ivkamakin@gmail.com
Telegram: @van0k
Questions?

Más contenido relacionado

Similar a ICO protocols & implementations - Ivan Kamakin - Codemotion Amsterdam 2018

Initial coin offerings: Financing growth with cryptocurrency token sales: Dig...
Initial coin offerings: Financing growth with cryptocurrency token sales: Dig...Initial coin offerings: Financing growth with cryptocurrency token sales: Dig...
Initial coin offerings: Financing growth with cryptocurrency token sales: Dig...OECD, Economics Department
 
Ico processes n_li
Ico processes n_liIco processes n_li
Ico processes n_linikinew1
 
Blockchain general presentation nov 2017 v eng
Blockchain general presentation nov 2017 v engBlockchain general presentation nov 2017 v eng
Blockchain general presentation nov 2017 v engDavid Vangulick
 
Analytic Ideas to Address Exchange Fake Volumes and Liquidity
Analytic Ideas to Address Exchange Fake Volumes and LiquidityAnalytic Ideas to Address Exchange Fake Volumes and Liquidity
Analytic Ideas to Address Exchange Fake Volumes and Liquidityintotheblock
 
Blockchain-Presentation.pptx
Blockchain-Presentation.pptxBlockchain-Presentation.pptx
Blockchain-Presentation.pptxMeganaaGodhala
 
Ergo platform overview
Ergo platform overviewErgo platform overview
Ergo platform overviewDmitry Meshkov
 
Overview of bitcoin
Overview of bitcoinOverview of bitcoin
Overview of bitcoinAbdul Nasir
 
Second Layer Execution Markets, 7/17/18
Second Layer Execution Markets, 7/17/18Second Layer Execution Markets, 7/17/18
Second Layer Execution Markets, 7/17/18ChronoLogic
 
Bitcoin - An introduction to a decentralised and anonymous currency
Bitcoin - An introduction to a decentralised and anonymous currencyBitcoin - An introduction to a decentralised and anonymous currency
Bitcoin - An introduction to a decentralised and anonymous currencyAndyBrodieLocima
 
How to not Destroy Millions in Smart Contracts
How to not Destroy Millions in Smart ContractsHow to not Destroy Millions in Smart Contracts
How to not Destroy Millions in Smart ContractsLeonid Beder
 
Transaction Ordering System
Transaction Ordering SystemTransaction Ordering System
Transaction Ordering SystemJasonGilchrist3
 
Fundamentals of Cryptoeconomics
Fundamentals of CryptoeconomicsFundamentals of Cryptoeconomics
Fundamentals of CryptoeconomicsPranay Prateek
 
Blockchain and Bitcoin.pptx
Blockchain and Bitcoin.pptxBlockchain and Bitcoin.pptx
Blockchain and Bitcoin.pptxssuser3ab054
 
Meeting 3 - Mechanism of trading (Capital market)
Meeting 3 - Mechanism of trading (Capital market)Meeting 3 - Mechanism of trading (Capital market)
Meeting 3 - Mechanism of trading (Capital market)Albina Gaisina
 
MyCrypto Release 9/14/18
MyCrypto Release 9/14/18MyCrypto Release 9/14/18
MyCrypto Release 9/14/18ChronoLogic
 

Similar a ICO protocols & implementations - Ivan Kamakin - Codemotion Amsterdam 2018 (20)

Initial coin offerings: Financing growth with cryptocurrency token sales: Dig...
Initial coin offerings: Financing growth with cryptocurrency token sales: Dig...Initial coin offerings: Financing growth with cryptocurrency token sales: Dig...
Initial coin offerings: Financing growth with cryptocurrency token sales: Dig...
 
Ico processes n_li
Ico processes n_liIco processes n_li
Ico processes n_li
 
Managing Initial Coin Offerings
Managing Initial Coin OfferingsManaging Initial Coin Offerings
Managing Initial Coin Offerings
 
Blockchain general presentation nov 2017 v eng
Blockchain general presentation nov 2017 v engBlockchain general presentation nov 2017 v eng
Blockchain general presentation nov 2017 v eng
 
Analytic Ideas to Address Exchange Fake Volumes and Liquidity
Analytic Ideas to Address Exchange Fake Volumes and LiquidityAnalytic Ideas to Address Exchange Fake Volumes and Liquidity
Analytic Ideas to Address Exchange Fake Volumes and Liquidity
 
Blockchain-Presentation.pptx
Blockchain-Presentation.pptxBlockchain-Presentation.pptx
Blockchain-Presentation.pptx
 
Ergo platform overview
Ergo platform overviewErgo platform overview
Ergo platform overview
 
Blockchain
BlockchainBlockchain
Blockchain
 
Overview of bitcoin
Overview of bitcoinOverview of bitcoin
Overview of bitcoin
 
Second Layer Execution Markets, 7/17/18
Second Layer Execution Markets, 7/17/18Second Layer Execution Markets, 7/17/18
Second Layer Execution Markets, 7/17/18
 
Bitcoin - An introduction to a decentralised and anonymous currency
Bitcoin - An introduction to a decentralised and anonymous currencyBitcoin - An introduction to a decentralised and anonymous currency
Bitcoin - An introduction to a decentralised and anonymous currency
 
How to not Destroy Millions in Smart Contracts
How to not Destroy Millions in Smart ContractsHow to not Destroy Millions in Smart Contracts
How to not Destroy Millions in Smart Contracts
 
Transaction Ordering System
Transaction Ordering SystemTransaction Ordering System
Transaction Ordering System
 
Fundamentals of Cryptoeconomics
Fundamentals of CryptoeconomicsFundamentals of Cryptoeconomics
Fundamentals of Cryptoeconomics
 
Ico (1)
Ico (1)Ico (1)
Ico (1)
 
bitcoin
bitcoinbitcoin
bitcoin
 
Blockchain and Bitcoin.pptx
Blockchain and Bitcoin.pptxBlockchain and Bitcoin.pptx
Blockchain and Bitcoin.pptx
 
15-Bitcoin.pptx
15-Bitcoin.pptx15-Bitcoin.pptx
15-Bitcoin.pptx
 
Meeting 3 - Mechanism of trading (Capital market)
Meeting 3 - Mechanism of trading (Capital market)Meeting 3 - Mechanism of trading (Capital market)
Meeting 3 - Mechanism of trading (Capital market)
 
MyCrypto Release 9/14/18
MyCrypto Release 9/14/18MyCrypto Release 9/14/18
MyCrypto Release 9/14/18
 

Más de Codemotion

Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Codemotion
 
Pompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyPompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyCodemotion
 
Pastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaPastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaCodemotion
 
Pennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserPennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserCodemotion
 
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Codemotion
 
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Codemotion
 
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Codemotion
 
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 - Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 - Codemotion
 
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Codemotion
 
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Codemotion
 
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Codemotion
 
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Codemotion
 
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Codemotion
 
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Codemotion
 
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Codemotion
 
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...Codemotion
 
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Codemotion
 
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Codemotion
 
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Codemotion
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Codemotion
 

Más de Codemotion (20)

Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
Fuzz-testing: A hacker's approach to making your code more secure | Pascal Ze...
 
Pompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending storyPompili - From hero to_zero: The FatalNoise neverending story
Pompili - From hero to_zero: The FatalNoise neverending story
 
Pastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storiaPastore - Commodore 65 - La storia
Pastore - Commodore 65 - La storia
 
Pennisi - Essere Richard Altwasser
Pennisi - Essere Richard AltwasserPennisi - Essere Richard Altwasser
Pennisi - Essere Richard Altwasser
 
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
Michel Schudel - Let's build a blockchain... in 40 minutes! - Codemotion Amst...
 
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
Richard Süselbeck - Building your own ride share app - Codemotion Amsterdam 2019
 
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
Eward Driehuis - What we learned from 20.000 attacks - Codemotion Amsterdam 2019
 
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 - Francesco Baldassarri  - Deliver Data at Scale - Codemotion Amsterdam 2019 -
Francesco Baldassarri - Deliver Data at Scale - Codemotion Amsterdam 2019 -
 
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
Martin Förtsch, Thomas Endres - Stereoscopic Style Transfer AI - Codemotion A...
 
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bul...
 
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
 
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
 
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
Sascha Wolter - Conversational AI Demystified - Codemotion Amsterdam 2019
 
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
Michele Tonutti - Scaling is caring - Codemotion Amsterdam 2019
 
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
Pat Hermens - From 100 to 1,000+ deployments a day - Codemotion Amsterdam 2019
 
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
James Birnie - Using Many Worlds of Compute Power with Quantum - Codemotion A...
 
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
Don Goodman-Wilson - Chinese food, motor scooters, and open source developmen...
 
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
Pieter Omvlee - The story behind Sketch - Codemotion Amsterdam 2019
 
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
Dave Farley - Taking Back “Software Engineering” - Codemotion Amsterdam 2019
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
 

Último

IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 

Último (20)

IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 

ICO protocols & implementations - Ivan Kamakin - Codemotion Amsterdam 2018

  • 1. ICO protocols and implementations Ivan Kamakin AMSTERDAM | MAY 8-9, 2018
  • 2. 2 Prerequisites • Beginner-level Solidity (should have been covered in a previous talk) • Should generally know how blockchain and Ethereum work • Beginner-level economics and game theory
  • 3. 3 Quick notes about implementations • No token-specific logic • There’s going to be some self-explanatory modifiers, like onlyOwner – they’re taken from OpenZeppelin reference implementations • The examples are simplistic and purposefully feature-poor
  • 4. 4 Motivation • DLT is the most multi-faceted state-of-the-art technology • In blockchain or DLT economics and tech are inseparable • It’s your job too ensure that an ICO accomplishes the goals of the business • It’s also your job to ensure it doesn’t go up in flames
  • 5. 5 Ancient history • Mastercoin (2013, now called OMNI) is generally believed to be the first ICO – an uncapped sale • Ethereum – 2014 – also uncapped • Not very sophisticated models due to limitations in instruments • A lot of ICOs accepted contributions in different coins – not done anymore due to arbitrage risk
  • 6. 6 Really easy to implement Uncapped sales IMintableToken token; uint public startBlock; uint public endBlock; uint public exchangeRate; uint public weiRaised = 0; Contract attributes modifier onlyWhenOngoing() { require(block.number < endBlock && block.number >= startBlock); _; } Modifier to only receive payments only when the ICO is running
  • 7. 7 Really easy to implement Uncapped sales function buyTokens(address buyer) public payable whenNotPaused onlyWhenOngoing { require(buyer != 0x0); require(msg.value != 0); uint boughtTokens = getValueWithBonus(exchangeRate*msg.value); weiRaised += msg.value; token.mint(buyer, boughtTokens); } function getValueWithBonus(uint value) private view returns (uint) { // Specific bonus calcualtion rules here. return value; } Bonus calculation A function to buy tokens constructor( uint _startBlock, uint _exchangeRate, uint duration, address tokenAddress ) public { owner = msg.sender; startBlock = _startBlock; endBlock = _startBlock + duration; exchangeRate = _exchangeRate; token = IMintableToken(tokenAddress); } Contract constructor
  • 8. 8 Really easy to implement Uncapped sales Fallback A function to withdraw Ether from the contract function() public payable { buyTokens(msg.sender); } function withdrawFunds(address withdrawAddress, uint amount) public onlyOwner { require(withdrawAddress != 0x0); require(amount != 0); withdrawAddress.transfer(amount); }
  • 9. 9 Uncapped sales • Simple model – just publish an address/contract and receive money • Unlimited participation But: • Uncertainty of valuation
  • 10. 10 Uncapped sales Theoretical Nash equilibrium Empirical evidence Indirectly lead to congestion Picture: Ethereum token sale stats by Vitalik Buterin
  • 11. 11 Uncapped sales Examples • Mastercoin, Ethereum, Antshares (now NEO) – almost every ICO before 2016 • The DAO • NXT – fixed token supply, but uncapped – we will see iterations on this model later • Tezos – the more recent example OpenZeppelin’s standard crowdsale reference implementation is an uncapped sale
  • 12. 12 Capped sales • Instead of accepting tokens from anybody, set a maximal capitalization • Stop the sale upon reaching the cap • You can even set the cap in fiat if you have an oracle • Tricky to implement in Bitcoin, as you have no direct way to stop accepting payments – that’s why it wasn’t really popular until Ethereum
  • 13. 13 Really easy to implement Capped sales Contract attributes IMintableToken token; uint public maxCap; uint public exchangeRate; uint public weiRaised = 0; function buyTokens(address buyer) public payable whenNotPaused { require(buyer != 0x0); require(msg.value != 0); require(weiRaised + msg.value <= maxCap); uint boughtTokens = getValueWithBonus(exchangeRate*msg.value); weiRaised += msg.value; token.mint(buyer, boughtTokens); } One new check compared to uncapped
  • 14. 14 Really easy to implement Capped sales Constructor constructor( uint _maxCap, uint _exchangeRate, address tokenAddress ) public { owner = msg.sender; maxCap = _maxCap; exchangeRate = _exchangeRate; token = IMintableToken(tokenAddress); } Those are all the changes
  • 15. 15 Capped sales • Also very simple – the only new variable is the hardcap • Valuation is strictly defined • Incentivizes to enter early But: • Uncertainty of participation • Causes network congestion and “fee wars” (see BAT)
  • 16. 16 Two sides of a really bad coin Uncapped sales • Not really a good way to attract reasonable investors • Can behave weirdly from game-theoretic point-of-view • Will attract a lot of attention from adversaries if the final valuation is very big • May cause regulatory problems Capped sales • Incentivizes gold-rush mentality • Easy for “whales” to push out other investors • Network congestion
  • 17. 17 Reverse Dutch Auction • Capped crowdsale • The purchasing power of investors’ contributions grows over time (which means the total valuation falls over time) • If an investor buys at some point in time, then his percentage of tokens at the end of the sale will not be lower than at that point
  • 18. 18 Reverse Dutch Auction Contract attributes IMintableToken token; uint public maxCap; uint public startBlock; uint public endBlock; uint public bpPerBlock; uint public weiRaised = 0; mapping(address => uint) bids; modifier onlyWhenOngoing() { require(block.number < endBlock && block.number >= startBlock); _; } modifier onlyAfterSale() { require(block.number >= endBlock); _; } Modifiers
  • 19. 19 Reverse Dutch Auction Constructor constructor( uint _maxCap, uint _startBlock, uint duration, address tokenAddress ) public { owner = msg.sender; maxCap = _maxCap; startBlock = _startBlock; endBlock = _startBlock + duration; token = IMintableToken(tokenAddress); } function makeBid(address _bidder) public payable onlyWhenOngoing { require(_bidder != 0x0); require(msg.value != 0); require(weiRaised + msg.value <= maxCap); bids[_bidder] = msg.value; weiRaised += msg.value; if (weiRaised == maxCap) { endBlock = block.number + 1; } } A function to place a bid in the auction
  • 20. 20 Reverse Dutch Auction A function for the bidder to withdraw their tokens function withdrawFunds(address withdrawAddress, uint amount) public onlyAfterSale onlyOwner { require(withdrawAddress != 0x0); require(amount != 0); withdrawAddress.transfer(amount); } A function to withdraw collected Ether function receiveTokens() public onlyAfterSale { require(bids[msg.sender] != 0); uint saleDuration = endBlock - startBlock; uint soldSupply = (token.totalSupply()*bpPerBlock*saleDuration)/10**5; uint bidderFraction = (10**18 * bids[msg.sender]) / weiRaised; uint bidderTokens = (bidderFraction*soldSupply)/10**18; token.mint(msg.sender, bidderTokens); bids[msg.sender] = 0; }
  • 21. 21 Reverse Dutch Auction Picture: Gnosis sale model by Gnosis Team
  • 22. 22 Reverse Dutch Auction • The model doesn’t have uncertainty of valuation, as it is essentially a capped sale • Doesn’t solve uncertainty of participation directly, but circumvents it • More resistant to “whales” because the remaining part of supply can be used in clever ways
  • 23. 23 Reverse Dutch Auction Important example – Gnosis sale ≈0.33 ≈0.05
  • 24. 24 Other mechanisms • Proportional refund • Hidden caps • Multi-round sales • Uncapped with fixed supply These mechanisms can be used in capped and uncapped sales and Dutch Auctions and combined among each other.
  • 25. 25 Proportional refund • If the total amount raised is 𝑝 and the hardcap is 𝑞 ≤ 𝑝, then 𝑝−𝑞 𝑝 is refunded to each contributor. • A kind of a balancing act between uncertainties of participation and valuation • It would be good to research investor preferences (mainly their marginal utility respective to token percentage) before using this mechanism • Works great in multi-round sales
  • 26. 26 Hidden caps • As in blockchain all data is open we will need an additional transaction – the hidden cap reveal may get stuck due to this • Weird on its own, as it removes certainty of valuation without adding anything • However, could be a great “whale” deterrent if used smartly
  • 27. 27 Multi-round sales • Work great with other mechanisms, as we’ve seen • Allow to give more control over the funding to investors
  • 28. 28 Uncapped with fixed supply • The same thing as proportional refund, only without the refund • Isn’t particularly useful, aside from an interesting multi-round model
  • 29. 29 State-of-the-art • Interactive Coin Offerings by Teutsch, Buterin, Brown (2017) • Direct-to-Market Dutch Auction by Darryl Morris (2017) • DAICO by Buterin (2018)
  • 30. 30 Interactive Coin Offerings • An uncapped sale • Contributors can place bids and withdraw them until a certain moment called “withdrawal lock” • A fraction of the bid that cannot be withdrawn grows with time • Each contributor also submits a valuation cap with their bid • After the withdrawal lock the contract automatically removes the bids with caps exceeded by the current valuation at each time step
  • 31. 31 Interactive coin offerings • Valuation monotonically increases • Very resistant to attacks and stretched out in time • It neutralizes uncertainty of valuation by allowing contributors to interact and collaboratively arrive to optimal valuation, and a contributor can opt-out from unsatisfactory valuation However: it is tough to implement
  • 32. 32 DTM Dutch Auction • A Dutch Auction sale, but it proceeds a bit differently • Instead of raising the percentage sold, the total amount of tokens is divided into lots • Lots are made available for purchase sequentially, with each next lot costing a fraction of previous one • This proceeds until all the lots are released • However, unsold lots remain on the order book
  • 33. 33 DTM Dutch Auction • Creates a possibility for secondary-market funding • Could induce some gold-rush mentality after market-price discovery, but this could be neutralized with proportional refund for each lot
  • 34. 34 DAICO • Funds are raised with any ICO model • However, they cannot be used by the team immediately • The investors control how much funds the team can withdraw in a block • They can vote to either raise this amount or destroy the contract and proportionally refund the remaining Ether to contributors
  • 35. 35 DAICO • A model is easy to understand • Gives the investors ability to control funding, removing a lot of concerns on valuation • However, the crowdsale should probably be “whale”-resistant • The voting system has to be carefully designed
  • 36. 36 That’s a wrap Github repository: https://github.com/Van0k/CodemotionContractExampl es Contract examples and links are all there My contacts: Email: ivkamakin@gmail.com Telegram: @van0k

Notas del editor

  1. So today I will be talking about ICO protocols and token sale models
  2. A couple of words about prerequisites: Generally don’t feel discouraged, if you don’t have anything that’s listed here – those aren’t necessary, but sufficient. So even if you haven’t touched Solidity before, you should be able to read most of the code. I’m going to talk a lot about economics and game-theoretic qualities of different models, but it’s going to be nothing that requires a PhD in economics. So, in essence, bear with me.
  3. I’m going to show some examples in Solidity, there’s going to be a Github link in the end, where you’ll find all the contracts and some useful links When I’ll be discussing these contracts, I will omit the token logic – we will always assume that the token sale contract has some means to mint new tokens or send them to the buyer and that respective functions are token functions I’ll have some basic contracts that the contract inherits from, like Ownable or Pausable (the names are self-explanatory), I will not discuss them with the rest of the code, you will just see some modifiers from them, but they have obvious names, like onlyOwner means that only the owner’s address can call the function I’ll keep the contracts as short and simple as possible, to the point of: “It should work, but only with the most fundamental functionality”. And if you need some more sophisticated features, you can add them yourself on top of the examples, using some links from the repository.
  4. So why should the smart contract developer know about economic properties of token sales and how these sales work? The reason I initially got into this whole DLT sphere is because it stands at an intersection of numerous disciplines – computer science, cryptography, economics and game theory. It’s simply very fun to analyze the sphere and its protocols and models. So I think that might be a reason as good as any. But you are likely also wondering how it could help you professionally, and the answer is that technology and underlying economic theory are tightly bonded when you do a tokensale, so it’s going to be really hard to only concern yourself with one separated from the other. Mostly because the best token model will be chosen based on the project’s stakeholders and how it suits them. But the model then has to be implemented, and it’s going to be your job to work closely with the business people to work out the kinks in the implementation. For example, you must be able to give argumentation on why this or that part of the model is not possible or reasonable in a smart contract. Finally it’s your job to ensure that the smart contract matches the model and that the model doesn’t get broken because of discrepancies.
  5. A bit about how it all started: The first ICO known of is Mastercoin in 2013. It was very simple uncapped sale, which means you publish an address and you receive blockhain’s native tokens onto it. Here it was a Bitcoin address, and the respective Mastercoins were sent to Bitcoin users as well, because it was supposed to be an overlay network above Bitcoin. Then there was Ethereum which also received funding in Bitcoins. Considering that Bitcoin doesn’t support sophisticated coding possibilities, the models back then were quite simple. Also a lot of crowdsales accepted different coins, however, this led to discrepancies due to different exchange rates, so it’s not done anymore.
  6. So how an uncapped sale would look in Solidity? Here we have some attributes – there is the token interface attribute and other parameters. There is also a custom modifier which controls whether an ICO is currently in process (just checking if the current block is between the beginning and an end).
  7. Then we have the constructor, basically just some assignments. You input the token address, and then in solidity it can be cast to a contract or interface type. There a bonus calculation function, which is a stub now, but could allow you to calculate the bonus based on current block (OpenZeppelin has an example of such function). Finally, there is a function for buying tokens which the buyer calls. It just calculates the amount and sends it to specified address using some token function.
  8. Finally, there is a fallback function, which is called when money is sent to the contract without calling anything specific (here it just promptly calls buyTokens). Finally, there is a function allowing the organizer to withdraw collected Ether. And that is pretty much all.
  9. So let’s analyze some of the properties of uncapped sales. It’s a very simple model – the contract without the token and parent contracts takes just about 60 lines of code. It’s also very simple for the investors, as the participation is unlimited, so all you do is just send money. However, there is one major drawback, because of which this model isn’t used anymore, and that is uncertainty of valuation. More sophisticated investors will want to leverage the percentage of coins they have, so, for example, they would be willing to pay 100k USD for 1% of the tokens, but here the tokens are created indefinitely, and they have no way of predicting the percentage of tokens they will have. And this is bad. This means that the investors you attract onto your platform do not consider such things, so those aren’t really very thoughtful investors, unless they like your project out of fundamental analysis considerations.
  10. Another weird property of uncapped sales is that they may indirectly lead to congestions due to some game-theoretic properties. If we look at the Ethereum sale, we’ll see that there was a period from the start to some point in time where the price of a single Ether was smallest. And the optimal way for the investors to behave in such situation is to wait until the end of this period to decide whether to invest or not. It’s pretty simple to show that this is a Nash equilibrium – if a single investor makes a decision earlier, then he has no market information, since everybody decide after him, and his position is worse. If he decides later, then he loses a part of the bonus, and his position is in the best case the same (if he makes a decision not to invest). And we see that this theoretical equilibrium is supported by evidence, as the peak of purchases is a little before the final moment of minimal price. And obviously, if the crowdsale is very popular, then the network may not be able to process the transactions in this equilibrium point fast enough, leading to congestion. If there’s no bonus period, then this equilibrium will be at the very end of the crowdsale.
  11. Examples of uncapped sales include a lot of crowdsales from before 2016, and for more recent examples, the infamous DAO and Tezos. Two of these projects is another reason not to do an uncapped sale – because in a case of some failure the potential damage has no upper limit. The DAO was hacked for 50 million and Tezos got 400 million locked up due to founder dispute. There is also an interesting example of NXT. They had a fixed token supply, which was distributed among investors proportionally to their contributions. Now this model with modifications is actually used quite frequently.
  12. So now let’s talk about a different model – capped sales. The difference from uncapped is that there is a limit to total amount of contributions. It may be set in crypto or fiat, but if you want to use fiat in a smart contract, you’ll need an oracle, like oraclize.it. They have gotten popular after 2015, because they are much easier to do in Ethereum than Bitcoin.
  13. We don’t have to change much to implement a capped sale, the attributes are going to be a bit different, with the new maxCap field. In buyTokens we only have to change modifiers and add a requirement of an additional contribution not exceeding the cap.
  14. Finally, we have to change the constructor to accommodate new attributes and that’s it.
  15. Capped sales are also very easy to understand and now the token’s valuation is fixed, so the investor knows which percentage of coins they buy. Also, because the demand for tokens is in most cases higher than the supply, investors are incentivized to participate early, or they risk being too late. However, here also comes the main problem – the army of investors trying to get in may pretty much stop the network in its tracks with their transactions. One of the most severe examples is Basic Attention Token – a 35 million crowdsale finished in half a minute, 135 transactions were successful, while about 10000 failed. More than that, 70 Ether, which is about 15000 USD, were spent on fees. The investors have started a fee auction to ensure their transaction gets into a block. The biggest fee was actually about 6500 USD. The network continued to process ICO transactions for 3 hours after the sale ended. These fee auctions are a paradise for large scale investors, or “whales” – they can push out smaller investors by setting humongous fees, and then your project will end up with half a dozen token holders that can manipulate price all they want. Such things are never good for the image of the token.
  16. To summarize, we see that these solutions on their own have severe economic downsides. Uncapped sales are not very just towards investors, can indirectly lead to network congestions and may even be a deal-breaker for the regulator, as they will frown upon a fundraiser without a set target cap. At the same time capped sales promote gold-rush and Fear of Missing Out mentality, which leads to oversubscription, fee wars and network congestion. But problems with these simpler models have sparked a lot of innovation in this area. Now we’re going to discuss one more major model that is becoming more and more popular by the day, then I will talk about some more exotic modifications and state-of-the-art.
  17. So without further ado, we proceed to the reverse dutch auction. This model is a capped crowdsale model, but with a twist. In a reverse dutch auction we have a fixed cap, but the percentage of tokens purchased with that cap increases over time, so, for example, it starts at 5% and grows to 95% by the end of the sale. Let’s first look at the implementation, and then I will discuss its economic properties.
  18. The new attributes for us are bpPerBlock, which means basis points per block. Basis point is 0.01%. And we also define a mapping between bidder addresses and their bids. We already had modifier onlyWhenOngoing in the uncapped sale, now we also have onlyAfterSale, you will see why a bit later.
  19. There is nothing new in the constructor, but buyTokens is now replaced with the new makeBid function. Instead of sending the tokens to the buyer right away, it instead writes the bid into memory. And if the maximal cap is reached, the crowdsale is closed by setting the end block.
  20. Now the bidder withdraws their earned tokens in a separate function, because calculating the value and sending it to each bidder automatically would be too computationally intensive (we would even not be able to fit into block gas limit). The function calculates the amount of sent tokens from tokensale duration. The function for the organizer withdrawal is mostly the same. There is also a fallback function calling makeBid, which I won’t show here – by now you know the drill.
  21. So let’s now discuss the economic aspects. I have a model of Gnosis sale here for a visual example. The mechanism of Reverse Dutch Auction facilitates a strategy at which the investor waits until the moment T with a maximal valuation that satisfies him to make a bid. If the crowdsale reaches this moment, then the investor makes a bid and gets at the worst the same amount of tokens that he would at the moment T. And if the crowdsale doesn’t reach it, then the investor stays out of a deal that doesn’t satisfy them anyway.
  22. So the cleverest thing about this model is how it approaches the uncertainty of participation. It doesn’t solve this uncertainty directly, but rather gives investors more market information, allowing them a more thoughtful decision on whether to invest or not. So if an investor could not participate before the end, it’s not as big a problem as it would be for them in a usual capped sale. And this model could achieve a more fair distribution of tokens by leveraging the remaining part of the supply. For example, if some whale decides to block other investors from an ICO and buys out the cap themselves early, then the team retains the bigger part of supply. This part could be put into a market-maker, airdropped to every address or sold at the next round.
  23. One important example is Gnosis sale. They were the first major Reverse Dutch Auction ICO. It’s important because it shows that even seemingly harmless changes to the model may cause unforeseen reaction. A couple of weeks before the sale after Gnosis announced their sale structure, a lot of their followers expressed concern about the team retaining the tokens that were not sold. It was a valid concern, as the team would have a central bank authority if the sale ended quickly. So the Gnosis team has decided to lock 90% of unsold tokens for a year. What happened then is interesting. The sale itself ended in the first day with about 5% of total tokens sold and big oversubscription, which would give Gnosis a gigantic valuation of about 250 million. This could be a very strong argument for the market players being irrational and not having an optimal valuation in mind at all. However, if we turn away from the total cap and instead analyze the result in short run, we will see that investors were rational. On a graph you can see a dependence of tokens in circulation before the end of one-year lockup from a fraction of total tokens sold. We see that the short-run valuation (which is sold tokens plus 10% of unsold ones) grows much faster with time than the total valuation. And while in total 5% of tokens were purchased, in short run this value is closer to 33%. Vitalik Buterin in his analysis further argues that the investors were rational even in the long run, because for the Gnosis team it makes sense to release locked tokens into the market only if they expect the price to go up as a result. So these locked coins aren’t dangerous even after one year. The lesson here is “Don’t make hasty changes to the model and carefully analyze how the optimal strategy changes after each change.”
  24. So those were 3 major models that have already been used and we have seen them in action. However, there are other small mechanisms and techniques that are used in different combinations with these big models. I will introduce them quickly and then discuss each of them in detail. The first one is proportional refund – it’s a capped sale, but instead of stopping the crowdsale at reaching the cap, you continue to accept contributions and after the sale divide the supply among investors proportionally to their contributions, while refunding the overcontributed amount. Hidden caps are pretty self-explanatory: the sale is seemingly uncapped, but there is a hidden cap that is manually revealed at some point. You can either just directly reject contributions or combine this with proportional refund. Multi-round sales – instead of having one big crowdsale, you organize several rounds with smaller caps Uncapped with fixed supply – it’s the same thing as proportional refund, but without the refund.
  25. Proportional refund is straightforward – you accept all contributions, even over the cap, then in the end the proportion of total amount raised that is overcontributed is calculated and the respective fraction of each contribution is returned to the contributor. The fixed percentage of tokens that is sold is divided proportionally among the contributors. This type of sale sacrifices some certainty of valuation to allow everybody to partially participate. Now an investor can be sure that they will get some amount of tokens at a fixed rate, but they cannot be sure which amount. And here it all comes down to investors’ personal utility functions. If their marginal utility is constant, meaning 1% of tokens for a 100$ is as good for them as 10% for a 1000$, then this solves all your problems – the total utility (taking into account the refund) is maximized. However, if investor’s satisfaction grows superlinearly with token percentage, then the value of the refund is not enough to counteract the utility loss. Unfortunately, practice shows that the second type of investors is more frequent, but it’s still good to know your investors. On the other hand, this mechanism works brilliantly in multi-round sales, as the refund allows the contributors to purchase more tokens in the next round, so their total utility after all rounds is much closer to optimal even if they are second type.
  26. So to implement hidden caps we will need some outside help, because in blockchain all information is open. To make the cap hidden but also eliminate a possible attack vector from the organizer, we first publish a hash of cap value concatenated to some random string for additional security. And then when it’s time to reveal the cap the organizers publish the cap and the random string into the blockchain. Then it’s trivial to compare the revealed cap and string to a published hash (it can even be a check in the reveal function). Here, if the ICO is oversubscribed, we can have a problem of hidden cap reveal transaction getting stuck. So you have to safeguard against that happening and somehow track the order of transactions to remove the excess transactions even if the hidden cap reveal was late. On its own it can be really strange, as it removes certainty of valuation, so you actually better off not using it for a hardcap. For example, Aragon used it as a damage control method – they set a very high hidden cap just to ensure that they don’t raise more funds than they could ever need and attract adversary attention, Also, you could use hidden caps as a whale deterrent in a capped sale. You set a lot of hidden caps that are not too far apart and are unlocked after some period of time, for example, daily. So this could partially solve inability to participate due to oversubscription or being pushed our by whales with high fees, because now the crowdsale is more stretched out in time, and it will be harder for a whale to suppress the rest of the network in this extended duration. Also, because these hidden caps are not so far apart, the whale cannot buyout everything in one fell swoop – they will have to split the purchase, incurring more transaction fees.
  27. We’ve already discussed multi-round sales a bit with other mechanisms, and have seen that they can improve other models substantially by simply extending the duration of crowdsale. Generally multi-round sales make your crowdsales more resistant to whale attacks, as they have to sustain the attack longer and spend more. They also increase the ability to participate, in an obvious way. Another cool feature is that multi-round sales can give investors an ability to better steer the project. A lot of investors are unsatisfied with a big valuation not because they are against giving a project a hundred million in general, but because they are opposed to giving this kind of money to an untested team with, at best, a prototype. But with a time-stretched multi-round sale investors can first give a team, say, 1 million and then track their progress and see whether to invest in the next round or not. Likely the only downside is that multi-round sales introduce more implementation complexity, which means more potential attack vectors for the adversary.
  28. So the last mechanism is often used in multi-round sales. It seems pretty crazy as-is, because it takes the worse parts of proportional refund and throws away the advantages, but there is an interesting example of its use by EOS crowdsale (which, I think, is still running). So, EOS started a crowdsale with a big first round, and then held a pause during which the token was listed on the exchanges. So essentially, the price at the ICO (which in this model would fluctuate freely based on the amount of round contributions) could converge to the market value of the token – if the last investor in the round sees that the price got higher than the market price due to other contributors, they will instead go and buy tokens at the exchange. Pretty much, that eliminates a lot of uncertainty with valuation and participation. The bad thing though, is that this introduces counterparty risks, as exchanges are well known to simulate turnover and manipulate token prices.
  29. In this final part I will tell you a bit about recent models, that were either not yet used or are just starting to be used. These might get complex at parts, so bear with me.
  30. Let’s first talk about Interactive Coin Offerings. This is a fairly complex model that was proposed in autumn 2017 in a paper by Jason Teutsch, Vitalik Buterin and Christopher Brown. Though this model has some great game-theoretic properties, I haven’t heard about it being yet implemented, probably because it’s not really trivial to code it up. The definition is as follows: the proposed model is an uncapped sale. It has two stages: “arbitrary withdrawals” and “automatic withdrawals”, separated by a withdrawal lock. These stages are separated by rounds. During both stages the contributors can submit a pair of a bid and a corresponding personal valuation cap. During the first stage, users can withdraw their bids arbitrarily, but the part of the bid is locked permanently and a part of their bonus is slashed as a result. During the second stage arbitrary withdrawals are no longer possible, but new bids can still be submitted. In this stage the smart contract keeps track of the active bids with minimal personal caps and partially or fully refunds these bids if the caps were exceeded by valuation.
  31. So what are the properties of this sale model? The valuation doesn’t decrease after any bid – that’s why bids are refunded either fully or partially depending on the situation to keep this invariant It is attack-resistant – there is no case where a rational adversary can get a bonus advantage by artificially inflating the valuation to keep other players out and then withdrawing their big bid – partial bid lockdown and bonus penalty counteract their advantage. It is resistant to push-outs as well, as it is stretched out in time. Finally, the killer feature is that it allows contributors to not only react to actions of other contributors while deriving their personal strategy, but, as the name suggests, interact. This pretty much makes uncertain valuation a non-problem, since each participant has much more information to decide their personal cap compared to a traditional sale, and in the end all remaining participants are satisfied with the cap and all unsatisfied quit the crowdsale. The problem is that implementation is tricky. While all previously described models can be implemented with constant-time functions, here automatically removing minimal cap bids requires maintaining some sorted data structures, and inserting new bids is non-constant with respect to total number of bids. This is problematic if there are a lot of bids, since the transaction can simply not fit into Ethereum’s block gas limit. The authors of the paper propose some hacks that could allow to solve that, like reducing the data structure size by binning bids by their cap value. Right now there is library by TrueBit foundation that can be used to bootstrap your own Interactive Coin Offering, but so far no major crowdsale has used it.
  32. Now I’m going to tell you about Direct-to-market Dutch Auction, which is a simple and interesting iteration on a normal Dutch auction. In this model, instead of raising the percentage of total tokens that is sold, the crowdsale releases equal-sized lots with exponentially dropping price. The market price is discovered once the some first lot is bought, but the lots with lower price are still released and will be bought below market price. However, those lots that are more expensive than market-price still remain on the order book and can potentially be bought out.
  33. So the idea here is that these remaining orders will be bought out once (and if) token price on the exchanges will reach their level, which allows the developers to get a reward if the project is successful and the token is doing great. There may be some problems with gold-rush mentality, as people try to buy out cheaper lots, but setting a proportional refund would pretty much be like setting a proportional refund in a multi-round sale, so this problem can be cured.
  34. Finally there is DAICO, a very recent proposal by Vitalik Buterin, which adds an element of a Decentralized Autonomous Organization to an ICO. First there is a funding round, which can use any arbitrary model or mechanism. But then the contract goes into the DAO stage, where the investors can vote on one of two actions: either to raise the so-called tap, which is amount of funds developers can withdraw from a contract per block, or to nullify the contract and proportionally refund the remaining Ether to investors.
  35. So this is a fairly simple model. The main advantage of this mechanism is that it largely neutralizes concerns on over-the-top valuation by implementing a more meritocratic approach – the investors can raise the tap if the developers are successful in realizing the project, or they can cut funding altogether if the team is malicious. However, there is some nuance in specific components of the model. The used ICO model should be resistant to whale pushouts, or the entire affair will turn into some kind of unregulated private equity by function, with only 5 addresses that can vote on resolutions. Also the voting system that Vitalik proposed is a stub, it simply counts votes from contributor addresses, which is very susceptible to Cybil attacks. Vitalik argues that Cybil attacks are reversible as long as the voting and the team are not simultaneously malicious, but reverting them still consumes time and fees. So it’s better to implement a more thoughtful voting system, for example, stake-based voting or quadratic voting. Though this is out of scope of this discussion, I’ll put some links into the Github repository.
  36. So, that’s pretty much all that I wanted to share. There is the promised Github link with contract code and useful links in Readme. And there are my contacts in case you need any help understanding and implementing this stuff – feel free to ask.
  37. Finally, any questions?