Background image by Nathan Anderson Blockchain, whether you like it or not, is changing the landscape of technology every day, and it doesn’t look like it is going to stop anytime soon. And the more we rely on this distributed network architecture, we are actually relying on its ability to conduct trades or transaction in the most transparent and trustless way possible. To achieve this, the blockchain technologies of today empower us with a very powerful tool — . Smart Contracts Smart contracts come in various flavors depending on what blockchain you choose, the most famous being the Ethereum smart contracts on Solidity at the moment, primarily because of its versatility (as it is Turing Complete). But there are other blockchain technologies out there which let you establish just as much… just in a different way. One such technology is , and it is what we chose as the fundamental tool set of our product — , and also to run its . Stellar TillBilly ICO There are multiple reasons why we chose Stellar, you can find out more in our , but one major reason was its simplified smart contract, something that we had unanimously agreed on right from the very beginning is a must for running an ICO. whitepaper was what (our advisor) said when I was discussing Stellar smart contracts with him. “Stellar smart contracts are still black magic for most” Johan Stén So hopefully this article will guide and possibly help others who wish to utilize SSC (Stellar Smart Contracts) and SDEX (Stellar Distributed Exchange) for running their ICOs. Let’s jump in! As the name suggests, this model deals with creating an intermediate account for every user who wishes to contribute towards the ICO. The main highlight here is that there exists an account between the contributor and company which is partially controlled by both parties through Stellar multi-signature feature. To make things simpler, let’s set up a few acronyms: Intermediary Account Contributing User COmpany conducting the ICO Stellar Distributed Exchange Stellar Smart Contract (or a fully formed unsubmitted transaction) Genesis Account (token issuer) ICO funds Holding Account Trusted Party IM: CU: CO: SDEX: SSC: GA: HA: TP: Key highlights: is the account where will transfer funds to IM CU The control of the secret key for resides fully with the and responsibility of funding (and activating) this account on Stellar remains in the hands of the IM CU CO is added as a signer on for partial control CO IM participates on (creates offer on) to buy the tokens and hold it for the duration of ICO IM SDEX On ICO success, no longer remains as a signer. This is handled via an and full control of goes to CO SSC IM CU On ICO failure, is still removed as a signer but the refund mechanism is handled by another on CO SSC HA Issuing account (genesis account) setup: One thing to note here — will need to have some control over the operations on itself, namely operations. This is because we want control over who can establish a trustline with our token and allowing trust is a low threshold operation. GA low threshold sends a set number of tokens to GA HA sets up its own sets of (explained later) HA SSCs performs the following operations: GA - Add as a signer with weight 1- Set its own weight to 1- Set authorization required flag- Set low threshold to 1- Set medium and high threshold to 2 TP This will allow to allow trustlines but will not allow it to make any more payment (token generation) transactions. GA Note: Since we have to allow trustlines throughout the duration of ICO, we cannot have a pre signed time locked transaction for clearing the authorization required flag after the ICO. After the ICO is concluded, the following transaction will be submitted (signed by both and ): GA TP - Clear authorization required flag- Reset thresholds- Remove as a signer- Set own weight to zero TP Setting own weight to zero will effectively render the account as worthless and no more tokens can be generated. User’s, however, can establish trustlines freely to trade these tokens. SSCs on ICO success or failure (key takeaways): will implement a multi signature with a on Stellar (could be a person, an organization etc.). HA TP holds all the tokens that are to be sold during the ICO. HA creates offer on to sell tokens for XLM HA SDEX A pre signed transaction with a set date determines the success or failure of ICO Success transaction will be time locked and with following operations (Seq number: M) - Send SOFT_CAP_AMOUNT to - Remove as a signer- Reset thresholds- Clear the offer on CO TP SDEX (If the ICO is not successful in raising the soft cap, this transaction will fail) Failure transaction, time locked (Seq number: M + 1) - Create an offer on to buy back tokens for XLM SDEX The challenge here is that we have to release all XLMs from in this case. Something that cannot be pre-written. So we’ll rely on again to create a transaction in this case or update the offer on with the right amount of XLMs. HA TP SDEX We will assume that all other prerequisites are met including website account creation, email verification, KYC and AML checks etc. User comes on to the dashboard and sees a button to create a wallet ( ). 1. IM Upon clicking, an offline Stellar keypair (only for the first time) is generated for the user. The secret is saved in the browser temporarily for the upcoming set of transactions. 2. User is prompted to save this keypair securely (An option can be given where we generate a keystore file locked with a password and save it on the server). 3. The user is then prompted to enter the secret key again in order to proceed with the next step. This is to ensure that user has saved the private key. 4. In the background (via xhr), we fund with 3 XLM thereby activating it (calculations later). The server responds with a success status along with ’s public key. 5. IM CO Upon successful activation, we create a transaction with following operations on (this transaction envelope (XDR) is sent to server instead of Stellar) 6. IM - Request trustline for token- Add as a signer with weight 1- Set all thresholds to 2- Set own weight to 1 CO Server submits this transaction on Stellar and then approves the trustline from the token issuing account. Wallet is now set up to receive funds (XLM) from external sources and ready to buy tokens from . 7. SDEX User is now presented a button to buy tokens. On clicking, we ask user to deposit XLM in from anywhere they want. It could be their own Stellar wallet or an exchange as well. 8. IM Browser shows a waiting status while it waits for an incoming transaction. We check this by using Server-Sent Events (streaming) mode. 9. Upon receiving funds, we create the following transactions (partially signing it using the secret key saved in the browser): 10. Transaction #1: (N) - Send 3 XLM to - Create an offer on to buy tokens for all but 3 XLM in account CO (recovering the account activation funds — one time only) SDEX Transaction #2: (N + 1) Time locked for the duration of ICO - Remove as a signer from this account- Reset thresholds CO Both transactions are sent to the server. Transaction #1 is signed by and submitted directly to Stellar network. Transaction #2 is signed and its hash and transaction envelope are saved on server. Server also returns these to the user if they want to verify and save it with them. 11. CO Every time the user wants to transfer funds, steps 8 to 11 are repeated. 12. The server will post this transaction #2 in step 10 upon completion of the ICO regardless the ICO succeeds or not. In case of when ICO is successful, the tokens are already in user’s account with full control of the account as well. The dashboard can provide quick and easy options to transfer these funds to a different account or merge it with another account etc. In case of when it fails, we are locked by a different set of which keeps both us and our users protected. We will again provide simple options on the dashboard to claim the funds back. SSCs Calculating minimum account balance for IM: Minimum balance required: 0.5 x (2 + # of entries) Every for ICO should have: IM 1 Trustline with the issuer’s token 1 Signer ( ) CO 1 Data entry (for handling bonus tokens, if required) Putting these values in the equation: 0.5 x (2 + 3) = 2.5 XLM Potential operations that will go through: IM Establish a trustline Set options (add signer, set thresholds, set own weight) Create offers on SDEX Transfer funds to user’s main account after ICO success Merge account with user’s main account Since the cost of these operations is not too high, having 0.5 XLM for fees is safe enough. So in total, each should have a minimum of 3 XLM deposited by the initially which can later be recovered. The real world (fiat) value can change depending on what is the cost of XLM at that point. IM CO That wraps it up! Now there can be more ways through which this model could be enhanced. For example: This was again suggested by Johan, in steps 2 through 4 in , you could use BIP-39 Mnemonic Code to ensure that contributing users indeed remember their secret keys. ICO sale process Another for when a user didn’t contribute at all and needs to recover the 3 XLMs transferred initially to activate the . SSC CO IM But this is something I’d leave up to you guys! Originally published by Aditya Moghe , engineering director at TillBilly — a forward-looking startup working on an innovative solution to bring blockchain based point of sale payments solution to the mainstream retail.
