Deep Dive into TokenOS — #1. Sale
TokenOS로 ICO를 파헤쳐보자 !
온더가 지향하는 목표 중 하나는 TokenOS라는 TaaS(Token-as-a-Service)를 만들어 ICO 자본시장을 합리화시키는 것입니다.
Series of TokenOS
- Intro to TokenOS
- Deep Dive into TokenOS — #1. Sale
- Deep Dive into TokenOS — #2. Account
안녕하세요 온더의 Danny 입니다 😃 이번 포스팅에서는 ICO 및 토큰 컨트랙을 자동으로 배포하는 툴, 온더의 TokenOS를 좀 더 자세하게 분석해보겠습니다.
본 문서를 포함해서 총 2개의 분석글이 연재될텐데요. 첫 번째 작성하는 주제는 토큰 세일(Sale)과 관련된 내용이고 두 번째 작성하는 주제는 팀이 받은 ETH 및 토큰을 보관하는 주소(Account)와 관련된 내용입니다.
해당 문서들을 통해서 ICO라는 것이 도대체 어떻게 진행되는 것인지, ICO가 어떤 구성요소로 이루어져 있는지를 많은 분들과 공유하고자 합니다.
P.S) TokenOS와 관련된 내용을 처음 접하시는 분들이라면, 상기의 “Intro to TokenOS” 문서를 먼저 읽고 오시는 편이 좋을 것 같습니다 :)
TokenOS는 별도의 컨트랙 개발 과정없이, 사용자가 원하는 스펙에 맞게 커스터마이징된 토큰 및 ICO 컨트랙을 자동으로 배포하는 툴입니다.
ICO = Token Sale Mechanism
지난번 TokenOS 관련 리포트는 dApp의 전반적인 소개와 함께 토큰 컨트랙트의 기능과 관련된 내용이 주를 이루었습니다. 오늘은 ICO의 구성요소 중 토큰 세일(Sale)과 관련된 사항들을 살펴보겠습니다.
ICO는 일반적으로 스타트업의 혁신적인 자금 조달 수단으로 평가받고 있는데요. 오늘 이야기할 내용들이 바로 ICO에 대해 가장 많이 논의되는, 즉 자금 조달 측면의 내용들이라고 할 수 있습니다. 이와 관련해서는 ONTHER DEVCON0에서 이미 여러가지 ICO 케이스에 대해 발표한 적이 있는데요.
본 문서에서는 TokenOS의 기능들을 살펴보며, 토큰이 판매되는 메커니즘으로서의 ICO는 어떤 요소로 이루어져 있는지에 대한 설명을 드리도록 하겠습니다. 본 문서를 통해서 토큰이 어떻게 판매되는지 알아볼 수 있는 기회가 되길 바랍니다 😌
우선, TokenOS가 제공하는 기능 가운데 Sale과 관련된 ICO의 구성요소는 다음과 같습니다.
1. Stage : 토큰 세일이 진행되는 횟수
2. Crowdsale : 전체 ICO의 자금 조달 파라미터
3. Period Bonus Stage : 토큰 구매 시의 기간 보너스 (Early Bird)
4. Amount Bonus Stage : 토큰 구매 시의 투자액 보너스
자, 그러면 이제부터 각 항목의 구성 요소들을 하나씩 살펴보겠습니다 :)
1. Stage
우선 ICO에서 Stage가 존재한다는 말은 어떤 의미일까요? 사실 우리는 이미 Stage라는 개념과 알게 모르게 많이 친숙해져 있습니다.
ICO에 관심이 있는 분들이라면 Private Sale, Public Sale 등의 용어를 많이 들어 보셨을겁니다. 일반적인 ICO의 경우 소수의 투자자를 상대로 Private Sale이 먼저 진행되고, 대중에게 토큰을 판매하는 Public Sale은 그 다음 차례로 진행이 됩니다.
다음의 예시 파라미터와 간단한 그림을 통해 좀 더 구체적으로 이해해보겠습니다.
ICO에서의 Stage란 ?
ICO를 위해 열심히 dApp을 제작하고 있는 한 팀이 있습니다. 이 팀은 토큰 세일을 총
3번
진행하고 싶어합니다.첫 번째 토큰 세일은 VC나 엔젤 투자자 등 소수의 투자자를 대상으로 진행되는 Private Sale을 계획하고 있으며, 나머지 2번의 토큰 세일은 대중을 대상으로 Public Sale을 진행하고자 합니다.
상기 시나리오의 경우, 총 3번의 토큰 세일이 진행되므로 Stage = 3
입니다.
이처럼, 토큰이 판매되는 구간이 일정 기간에 의해 구분되는 것을 Stage라고 합니다. 즉, 토큰을 판매함에 있어 토큰 세일을 몇 번 진행할 것인지를 결정짓는 변수라고 생각하시면 됩니다.
TokenOS는 ICO 팀이 자체적으로 Stage 관련 로직을 설정할 수 있게끔 다음과 같은 요소들을 변수로 지정해두었습니다.
상기 JSON 파일의 8~14줄에 해당하는 (key, value)
변수들은 특정 ICO 팀이 Stage와 관련하여 결정할 수 있는 각각의 구성 요소에 해당합니다. 뒤에서 설명할 나머지 요소들도 마찬가지구요. 그럼 이 요소들을 하나하나 살펴보도록 하겠습니다 :)
Components of Stage
Stage와 관련된 변수들은 다음과 같은 순서로 정해집니다.
Total_num_stages
: 전체 ICO 기간 동안, 총 몇 차례(m
)의 토큰 세일을 목표하고 있는지를 우선적으로 결정합니다.n_stage_start_time
: 특정 ICO Stage가 시작되는 시각을 의미합니다. 앞서 토큰 세일 Stage의 총 횟수(m
)가 결정되었다면,n=1
부터 시작하여 마지막m번째
Stage까지의 시작 시간을 설정해야 합니다.n_stage_end_time
:n
번째 세일 구간의 종료 시각을 의미합니다.n
번째 Stage의 종료 시각은n+1
번째 Stage의 시작 시각이 됩니다.n_stage_hard_cap
:n
번째 세일 구간에서 목표하는 최대 자금 조달액(Hard Cap)을 의미합니다.n_stage_max/min_purchase_limit
:n
번째 세일 구간에서, 투자자 1인당 구매할 수 있는 최대/최소 토큰 구매량을 의미합니다.n_stage_is_KYC
: 해당 Stage에서 KYC가 진행되는지의 여부를 결정합니다.
해당 Stage에서 KYC가 진행되는지의 여부를 묻는n_stage_is_kyc
응답까지 제출이 완료되면 n번째
Stage와 관련된 질의는 끝이 나게 됩니다.
다만, 만약 m ≥ 2
라면, 즉 전체 Stage가 2개 이상이라면 KYC 여부를 묻는 마지막 질문이 끝나고 첫 번째 질문으로 되돌아가게 됩니다. 새로운 스테이지에서 설정되어야 할 변수에 다시 대답해야 한다는 것이지요.
예를 들어, 총 4개
의 Stage를 두어 토큰을 판매하고자 한다면 Stage 내부의 각 변수들 역시4번
입력되는 것이 상식적입니다. 이를 플로우 차트로 그려보면 다음과 같은 흐름이 도출됩니다.
위 그림을 보시면 “3–7. n번째 스테이지는 KYC를 하나요?”라는 마지막 질문 이후에, (n+1)번째
스테이지가 시작되는 시각을 반복적으로 설정하는 로직을 확인하실 수 있습니다.
2. Crowdsale (= ICO)
다음으로 살펴볼 항목은 Crowdsale이라는 항목인데요. 일단 여기에서 이야기하는 Crowdsale은 ICO와 동의어라고 생각하시면 됩니다.
앞서 우리는 하나의 ICO가 진행될 때, 토큰을 판매하는 Stage는 여러개 설정될 수 있다는 것을 확인했습니다. 그리고 이러한 Stage들이 합쳐져 전체 ICO 토큰 세일을 이루지요.
이번 절에서 다룰 내용은 모든 Stage가 합쳐져 만들어지는 하나의 ICO에 대한 내용입니다. 즉, ICO의 거시적 측면과 ICO를 통해 조달되는 자금(ETH) 자체에 대한 이야기를 하고자 합니다.
언뜻 보면 느끼시겠지만, ICO의 전체 하드캡이나 시작/종료일 등 전체적인 틀에 해당하는 내용들이 입력되는 것을 보실 수 있습니다. 이제 각 질문들을 살펴보도록 하겠습니다.
Components of Crowdsale
Crowdsale과 관련된 변수들 역시 상기 JSON 파일에 명시된 순서로 정해집니다.
ether_hardcap
: 해당 ICO의 하드캡이 몇 ETH인지 설정합니다. 앞서 각 Stage에서도 토큰 세일의 하드캡을 지정했었죠? Crowdsale 항목에서의 하드캡은 Stage별 하드캡의 총합을 의미합니다. (ΣHard Cap of each Stage
=Total ICO Hard Cap
)
예를 들어, 총 2개의 스테이지가 있고 각각의 stage를 private sale, public sale로 지정합시다. 이 때 private sale의 하드캡을 200 ETH(
1_stage_hard_cap
)로 설정하고 public sale의 하드캡을 800 ETH(2_stage_hard_cap
)로 설정했다면, 전체 ICO에서의 하드캡인ether_hardcap
은 1,000 ETH가 됩니다.
ether_softcap
: 해당 ICO의 소프트캡이 몇 ETH인지 설정합니다. 소프트캡은 주로 ICO 전체에서 모이는 최소 자금 조달액을 의미합니다.start
: ICO의 시작일이 언제인지 설정해야 합니다.end
: ICO의 종료일이 언제인지 설정해야 합니다. 이 때, 개별 Stage의 시작/종료시점과는 달리, Crowdsale 항목에서의start / end
시점은 한 번만 입력하면 됩니다.base_rate
: 할인이나 보너스 등의 가격 차별이 적용된 값이 아니라,1 ETH = N 토큰
등 기본값으로 설정되어 있는 토큰의 가격을 의미합니다.ether_max_purchase_limit
: 해당 ICO에서 투자자 1명이 투자할 수 있는 최대 금액(ETH)을 의미합니다. 주로 고래 등의 자본 집단을 막기 위한 방법으로 활용됩니다.ether_min_purchase_limit
: 해당 ICO에서 투자자 1명이 최소한 투자해야 하는 금액(ETH)을 의미합니다.purchase_interval
: 특정 투자자가 토큰을 빠른 속도로 여러번 구매할 경우, 이더리움 블록체인 네트워크에는 혼란이 생길 수 있습니다. 이러한 투자 행위를 막기 위해서, 일정 시점이 지나야 재투자할 수 있는 로직이 설정되어 있습니다.
이 항목의 경우 문항이 반복되는 로직은 없습니다. 왜냐하면, 앞서 말씀드렸다시피 Crowdsale 항목은 하나의 ICO를 거시적으로 바라봤을 때 지정할 수 있는 변수들이기 때문입니다.
토큰 판매시의 가격 차별
Sale과 관련된 3, 4번째 항목들은 토큰을 판매할 때 토큰의 가격을 차등적으로 설정하는 기능과 관련된 내용입니다.
3. 기간 보너스(Period Bonus Stage) : 투자 “시점”에 따라 토큰 가격에 차별이 생김.
4. 수량 보너스(Amount Bonus Stage) : 투자 “금액”에 따라 토큰 가격에 차별이 생김.
우선, 투자하는 시점에 따라 토큰 가격을 다르게 설정하는 기간 보너스 정책부터 살펴보도록 하겠습니다.
3. Period Bonus Stage
위에서 언급했듯이, Period Bonus Stage라는 것은 투자에 참여하는 시점에 따라 토큰 가격에 차별을 두는 기간 보너스 정책(Periodic Bonus)입니다. 주로 얼리 버드(Early-Bird)라고도 불리지요.
이해를 돕기 위해서, 코드 레벨에서 파라미터들을 먼저 확인하지 않고 앞서 제시했던 Stage 구조와 함께 개념을 도식화해보겠습니다.
위 그림에서 보시는 바와 같이, 개별 토큰 세일 스테이지 안에서는 기간 보너스 구간이 여러개 존재할 수 있습니다. 각각의 토큰 세일 구간마다 ICO가 진행되는 것이니까요.
무슨 말인가 하면, 일단 위 그림에서는 기간 보너스 구간이 총 4개(A, B, A’, B’)가 있습니다. 그리고 ICO Stage 1에 진입하는 투자자들에게는 가장 많은 기간 보너스를 주되, Stage 1 내부에서 결정되는 보너스의 수량 및 퍼센티지는
A > B
일 것입니다.Stage 2에서도 동일한 논리로 보너스가 결정될텐데요. 단지 Stage 1보다는 더 적은 액수의 보너스가 투자자들에게 할당될 것입니다. 그리고 마지막 Stage 3에서는 기간 보너스를 아예 배제하는 형태의 ICO가 진행되고 있습니다.
일단 기간 보너스 구간에 대한 간략한 개념은 짚어보았습니다. 그러나 상기의 내용들이 말로만 적혀있기 때문에, 기간 보너스의 개념이 와닿지 않으실 수도 있는데요. 그렇다면 예시 파라미터를 가지고 좀 더 구체적인 논의를 이어가도록 하겠습니다.
Sample Periodic Bonus Scenario
위 표를 보시면, 총 3주에 걸쳐 토큰이 판매되고 있는데요. 일단 이 3주의 기간을 단일 Stage로 가정한다면, 1번의 토큰 세일 Stage 내부에는 총 3개의 기간 보너스 구간(1st Week, 2nd Week, 3rd Week)이 존재합니다. 앞서 보여드린 그림에서는, Stage 1 내부에 총 2개의 기간 보너스 구간이 있었는데 서로 무슨 차이인지 이해가 가시나요?
이제 토큰의 기간 보너스의 금액 을확인해보면, 1 ETH로 구매할 수 있는 토큰이 점차 줄어들고 있음을 확인할 수 있습니다. 즉, 시간이 지날수록 토큰의 가격이 비싸지고 있습니다.
토큰 세일의 마지막 스테이지인 셋째주에는 1 ETH로 살 수 있는 토큰이 2,000 Token까지 하락했습니다. 이는 곧 투자에 일찌감치 참여하는 사람일수록 토큰 할인 및 보너스 혜택을 많이 받는 것을 의미합니다.
이 때, 맨 마지막 스테이지에서의 토큰 가격(1 ETH = 2,000 Token
)은 우리가 앞서 Crowdsale 항목에서 지정했던 base_rate
, 즉 토큰의 기본 가격에 해당하는 것이 일반적입니다. 기본 가격이라는 말이 와닿지 않는다면, 토큰을 처음 발행할 때 책정하는 토큰의 액면가라고 생각하시면 편합니다.
Components of Period Bonus Stage
이제 기간 보너스 스테이지의 구성요소를 JSON 파일로 확인해보겠습니다. 개념은 다소 복잡했지만, 구성 요소들은 많지 않습니다.
num_bonuses
: 전체 기간 보너스 구간의 수를 의미합니다. 위 도식화된 그림에서 살펴봤던 것처럼, 하나의 토큰 세일 Stage에는 여러개의 보너스 구간이 결정될 수 있습니다. 따라서 전체 보너스 구간의 수는각 Stage 내의 Bonus Stage
를 모두 합한 값입니다.
위 표(3 Weeks ICO)에서 결정된 파라미터를 대입해보면, 해당 시나리오에서는 토큰이 판매되는 Stage가 1개밖에 없었으며, 그 안에 3개의 기간 보너스 구간이 있었습니다. 이 때, ICO에 존재하는 보너스 구간의 총 개수(
m
)는 3개입니다.
n_end_time
: 종료 시각의 경우, 앞서 언급했던 토큰 세일 Stage에서의 논리와 동일합니다. 첫번째 기간 보너스 구간의 종료 시점인1_end_time
은 두번째 기간 보너스 구간이 시작되는 시점과 일치합니다.
cf) 맨 처음 Stage의 시작 시각이 따로 없는 이유는, 앞서 살펴본 Crowdsale 항목에서 이미 ICO의 시작 시점을 입력했기 때문입니다.
n_bonus_rate
: 보너스 구간에서 적용되는 보너스 퍼센티지입니다.
위에서 살펴본 표에 의하면, 첫 번째 보너스 스테이지에서의 토큰 가격은
1 ETH = 3,000 Token
이었습니다.이는 토큰의 기본 가격(
base_rate
)인1 ETH = 2,000 Token
에 비해 50%만큼 많은 토큰을 기간 보너스 수량으로 할당받은 것입니다.두번째 스테이지에서는
1 ETH = 2,500 Token
이었으니, 25%만큼의 토큰을 추가로 할당받은 것이지요.
토큰 세일 Stage에서 살펴본 것과 마찬가지로, Bonus Stage가 2개 이상이라면 다음 Stage에서는 아래처럼 동일한 질문이 반복될 수 있습니다.
4. Amount Bonus Stage
마지막으로, 투자하는 금액에 따라 보너스를 부여하는 Amount Bonus Stage 기능에 대한 내용입니다.
Period Bonus Stage의 개념은 “투자 시점에 따라” 토큰 가격에 차등을 두는 것이었다면, Amount Bonus Stage는 “투자하는 금액에 따라” 토큰 가격에 차등을 두는 것입니다.
다만, 주의해야 할 점은 여기에서의 Stage는 기간에 따라 나눠지는 것이 아니라, | 1,000 ETH | 500 ETH | 100 ETH |
등 이렇게 투자하는 금액을 기준으로 나눠지는 Stage를 의미합니다. Ambrosus가 채택했던 토큰 가격할인 정책을 통해서 Amount Bonus를 좀 더 구체적으로 이해해보겠습니다.
위 표를 보시면, 투자액에 따라 토큰의 구매 가격에 차별(할인)이 이루어지고 있는 구간은 총 3개입니다.
i) 투자액 범위 : 300 ~ 1,599 ETH : 10% 할인
ii) 투자액 범위 : 1,600 ~ 3,199 ETH : 20% 할인
iii) 투자액 범위 : 3,200 ETH 초과 : 30% 할인
이처럼, “투자 시점"을 보너스의 구간으로 설정하는 Periodic Bonus와는 달리 Amount Bonus는 “투자액" 을 기준으로 보너스의 구간을 설정하고 있습니다.
Components of Period Bonus Stage
Amount Bonus는 “투자액"을 기준으로 보너스의 구간을 설정한다고 말씀드렸는데요. 관련 파라미터와 그 기능들을 좀 더 자세히 살펴보도록 하겠습니다.
is_amount_bonus
: 구매 수량 보너스의 여부를 묻는 질문입니다. 만약 수량 보너스를 두지 않는다면, 다음 주제의 질문으로 넘어가게 됩니다.num_amount_bonus
: 수량 보너스 구간을 몇개 두는지에 대한 질문입니다. 즉, 보너스를 받을 수 있는 투자액의 범위가 총 몇개(z
) 설정될 것인지를 묻는 것입니다. 앞서 살펴본 Ambrosus의 사례를 인용해보면,z = 3
의 수량 보너스 구간을 둔 것입니다.k_amount/bonus
: Ambrosus의 파라미터를 계속 사용하도록 하겠습니다. 총3
개의 투자액 범위 구간을 설정했다면 각 투자액 범위에 해당하는 보너스들을 수량 / 퍼센티지 기준으로 설정해야 합니다.
예를 들어,
k번째 구매 수량 보너스의 수량 / 퍼센트를 입력하라
는 질문은 다음과 같습니다.첫 번째 수량 보너스 구간의 투자액 범위가 “ 300 ~ 1,599 ETH”일 때, 투자액의 10%만큼 할인해준다면
amount = 1,599 ether | 300 ether
를 내림차순으로 입력하고,bonus = 10 %
로 입력하면 됩니다.
Conclusion
TokenOS의 기능 중 토큰의 Sale과 관련된 내용을 비교적 자세하게 소개해드렸습니다.
바로 다음 포스팅인 “Deep Dive into TokenOS — #2. Account” 에서는 ICO 과정에서, 그리고 ICO가 끝난 후에 팀에게 할당된 ETH와 토큰이 어떻게 분배되고 보관되는지를 설명해드리도록 하겠습니다 :)
추가로, TokenOS와 관련된 세부적인 구현은 아래 TokenOS 스키마 레포에서 확인하실 수 있습니다.
🌎 Github TokenOS Schema
- Q&A and More Communcation 😃 => danny.h@onther.io