A Short Story About Transactions

As a company, Visa dates back all the way to 1958. In those days, a temporary paper card was provided with a preset limit, and vendors settled transactions later at the bank. Next, mechanical embossing machines accomplished a similar feat. Still, vendors had to spend several minutes physically calling into Visa to verify and approve transactions that even then had to be later settled at the bank. It was not until two decades later, in 1979, when electronic payment terminals came about. Today, Visa is able to process nearly 60,000 transactions per second, yet on average, Visa only uses less than 3% of that capacity (1,600–1,700 transactions per second).

In recent years, mobile wallets have entered the transaction market. With encrypted payment codes to mask payment information, these wallets provide a more secure interaction with vendors; however, they also open a wider outlet of data flow directly to your phone. Why have more than 80% of Apple users held off on setting up Apple Pay while the rate of adoption for WePay and AliPay in China has skyrocketed? Perhaps, the exposure of consumer data has deterred Apple users?

Which brings me to the question: is it really about transaction speed? Yes, security is certainly a factor, but if we were purely after a faster transaction time for our money with more security, why aren’t more people in The West using mobile wallets? And to that end, why did anyone ever use Visa cards to begin with? At the start, they actually increased transaction time and complexity. [Granted, a caveat here is that these transaction innovations were accomplished with a stable, traditional fiat currency, but humor me and assume we are working with stable coins.]

If the past is any indication, Ethereum cannot scale through increased transaction time alone.

A Short Story About Pyramid Schemes

A pyramid (or Ponzi) scheme is system in which each paying participant is encouraged to recruit two or more new participants, and the payments of the new recruits are used to “pay off” the older ones. This occurs in the absence of a real sustainable revenue stream and often leads to a collapse. A thing about pyramid schemes: they are heavily dependent on scaling. Fortunately for the general public, pyramid schemes rely more on slower a peer-to-peer conversion system.

A friend of mine and her boyfriend recently encountered a set of recruiters for a pyramid scheme. Interestingly, these particular recruiters were a couple in search of other couples to join the system. Without a shadow of a doubt that they had encountered a pyramid scheme, my friend directly questioned, “What do you say to those who accuse this of being a pyramid scheme?”

Their answer? “Take a look at Wells Fargo or any other bank.”

After a few more minutes of back and forth, the female in the duo piped in with, “Well, with this program, if the woman is not on board with her significant other, we see a lot of relationships fail.”

To which my bold, heroine of a friend replied, “So, now you’re trying to convince me by threatening my relationship…?” Needless to say, that was about the end of the conversation, and they did not sign up for the program.

Still, how eerily similar are the arguments above to those of individuals or organizations endorsing cryptocurrency? How many times has someone brought up the centralized Federal Reserve and inflation as a retort to the lack of stability in Bitcoin or Ether? And thankfully, I have never encountered the irrationality of someone claiming that a lack of allegiance to cryptocurrency would destroy a relationship. Yet, is challenging one’s allegiance to a government, employer, or form of employment really all that different?

Ethereum cannot scale through the recruitment techniques and attempted persuasions of a ponzi scheme.

What Now?

If we are not going to recruit our way into scaling nor will we grow through increased transaction time alone, how will Ethereum scale?

To answer this question, my research began with scaling large systems that led me to this video in which Professor David West goes through the 2006 paper from Carnegie Mellon Ultra Large Scale Systems: The Software Challenge of the Future that details the hypothesized requirements of a superior large scale system. This paper was originally put together as part of an initiative from the United States Department of Defense and collected thought leadership from some of the top minds in the industry at the time. Although even Bitcoin was not around yet, the paper carried some surprising forethought into its design.

The Preservation of Decentralization

The paper postulated several ideas as to the growth of large scale systems and their essential requirements. Of all the challenges in creating a large scale system, speed was mentioned only four times in the 150 page paper! That’s not to say that speed is not important. But in building a robust large system, speed is not perceived as the biggest challenge.

However, in the paper, it is noted that an essential challenge to overcome when creating a large scale system is decentralizing its control.

So, does this mean Ethereum is already poised to scale better than existing centralized systems? I would argue, in the far out future, yes. If Ethereum wanted to scale transactions speed, this could be far more easily accomplished through centralizing the transaction processing, and in fact, examples already exist in systems all over the world from major corporations to governments. We are already capable of tremendous transaction speeds. What Ethereum ultimately wants to scale is not transaction speed, it is scaling decentralization. Thankfully, practical developers know that the general public will not forsake speed or convenience simply to participate in a “decentralized” system. So, one effort must pull the other.

To approach this challenge pragmatically, the Ethereum community is looking at Layer 1 and Layer 2 solutions. Layer 1 solutions include those that bring changes to the core code base of the Ethereum blockchain, while, as you may suspect, Layer 2 solutions are being built on top of the Ethereum blockchain. The simplest explanations of the ongoing efforts you’ll find in the table below.

Essentially, sharding mirrors traditional database sharding in which pieces of the database are spread across multiple locations. In Ethereum’s case, the blockchain would be spread across multiple nodes, so that each node would not have to verify, process and hold every transaction. This would help to speed up transaction time at the base chain level.

As to Layer 2 solutions, state channels use smart contracts to manage the exchange of value or a state offchain with final settlement happening on chain. For example, think of a traditional bar tab in which a bill may be opened at the beginning of the evening then accumulate a few drinks and close out, state channels open with a certain amount and certain set of participants, participants agree to exchanges of value or changes of state offchain, and final settlements are managed onchain. In the offchain interactions, these exchanges are managed essentially as instantaneous as current databases allow, ensure privacy, and do not require any transaction fees. A great primer on state channels is here, and I wrote an extensive piece on generalized state channels for developers as well here.

Plasma uses a similar methodology to state channels in which agreements and transactions are signed offchain; however, instead of changing solely a state, an entire second layer blockchain is built on top of the main chain. This is typically managed by a particular account or set of accounts that routinely sends “blocks” back to the main chain to be later verified. Both plasma and state channels experience challenges in exiting back to the main chain. This challenge is due to the fact that a time allotment is required to ensure malicious actors do not attempt to exit the plasma chain or the state channel with false information.

Lastly, TrueBit is an effort to move the computational portions of smart contracts off chain. More updates about TrueBit can be read here.

However, more than simply understanding these initiatives, it is far more interesting knowing the shear number of companies and organizations working to improve existing scaling solution implementations and make them a reality. For example, in the past months, new teams have engaged in the plasma implementation calls while cross project opportunities have been identified between the sharding and Casper, or proof of stake, teams. In other words, these projects are moving, and with the impending hard fork continuing to adopt even more Ethereum Improvement Proposals (EIPs), Ethereum has transitioned to a dynamic, constantly changing organism.

And that brings us to another element that is identified as a strength of large scale systems…

Continuous Evolution and Adaptation

In the Ultra Large Scale Systems paper, the evolution of a system is described in the following way:

Their size will make it impractical to replace or retire them. Instead, like very large systems today, they will continuously evolve to meet new and modified requirements and to incorporate new technologies. But we envision a different type of evolution than is typical of today’s very large systems. By evolution, we mean change that is guided and constrained by rules and policies that allow local needs to be satisfied in local ways without destroying the integrity and value of the overall system.

As described above, Ethereum is not meant to be retired or replaced — it is meant to evolve. However, how is the evolution of Ethereum “guided and constrained by rules and policies”? In 2013, the Ethereum Foundation raised $17M to build out the Ethereum blockchain. Since its inception the Ethereum Foundation has been the guiding organization in Ethereum’s continuous development.

With the iconic face of Vitalik appearing in articles and documentaries, it is easy for the those outside the Ethereum community to assume a monarchy exists. Yet, the reality is there are several diligent teams working across the globe to not only improve the core development processing but also to improve the governance process. Every two weeks the core developers call discusses the implementation and inclusion of varies improvement proposals, and this call often includes those outside the Ethereum Foundation. Even more than that the Fellowship of the Ethereum Magicians is a self-organized group of Ethereum enthusiasts further maximizing the advancement of the Ethereum ecosystem. Another consideration is Ethereum large pool of developers that rests at nearly 30 times more than the number of developers than the next most popular blockchain ecosystem. Thus, several people are experimenting and tinkering with the system everyday — not just as users, but as developers and builders.

Whether you are a user, a miner, a developer or a trader, each participant has a certain amount of say within the Ethereum ecosystem. The Ethereum Foundation has no quarterly financials to report to Wall Street, miners have a choice of the chain within which to use their computing power, and users are no more compelled to use Ethereum than they are to own a specific brand of cellphone.

The point is, the Ethereum will only scale and survive if each part of the community is served to a level that outshines alternatives. Unlike the ponzi scheme story, no form of coercion or get-rich-quick investment schemes will suffice because the true strength of a system is not its ability to persuade an audience but rather its ability to adapt and evolve to serve its ultimate purpose, which is to become a decentralized system that allows for the border-less transmission of value and information.

Lastly

Thus far, I’ve managed to avoid saying “the current Ethereum block time averages 15 seconds.” This strategy was not in an effort to avoid this statistic but rather emphasize that transaction time is only a fraction of the combined effort needed to scale the Ethereum ecosystem.

Without achieving a realistic transaction time, Ethereum will surely not be able to compete, so it is a necessarily metric that must be achieved in the short term through the most realistic means. However, preserving decentralization and ensuring continuous evolution will ensure a far more relevant future for Ethereum than achieving transaction speed alone.

Scaling Ethereum in the Context of Large Systems was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

To an outsider, understanding Ethereum might seem like a complex technical undertaking. But as a former outsider, it’s really not! This post serves to simply define key terms and concepts in the Ethereum network, so you’re equipped for schmoozing at the next conference afterparty that has the word ‘blockchain’ in its title.

What is Ethereum?

• The Ethereum blockchain is a public database that lets developers build and deploy decentralized applications. Think of it as a tool to create any decentralized online service.
• Bitcoin is a way to store and move digital value (e.g. “digital gold”), while Ethereum extends digital value to be programmable.
• Using advanced computation, Ethereum records its data in “smart contracts,” or computer code that can facilitate the exchange of anything of value.

The main benefits of Ethereum

• The Ethereum blockchain is a trusted source of information that you can be positive no one has tampered with
• People are rewarded in Ether (ETH) for validating transactions fairly AKA mining new blocks for the chain
• Unlike Bitcoin, Ethereum supports Turing completeness, so anyone can write any program to be executed on it. This makes it a good foundation for the aforementioned decentralized applications, or dApps.

What is Ether/ETH?

• Ether is the native token of the Ethereum blockchain, known shorthand as ETH. It is the required medium of exchange for paying fees to complete protocol-level computations on the Ethereum network.
• Ether (ETH) is the fuel for the blockchain. You need ETH to be able to update smart contracts and participate in the sending and buying of tokens. Note: People use Ether and ETH interchangeably.

How do I send transactions in Ethereum?

• Depending on which wallet provider you are using, it can be as simple as copy and pasting in the recipient’s wallet address, then typing out the amount of Ether you want to send.
• Optionally, you can add a gas price to your transaction to prioritize your transaction over others.

How Gas works on Ethereum

• Gas is the fee affixed to an Ethereum transaction that, depending on the limits the sender sets, can make a transaction happen faster or slower than others
• Like electricity, the price of Gas depends on demand at a given time

We’ll be writing more posts that serve as simple introductions to the core concepts in the Ethereum ecosystem. Stayed tuned.

Ethereum in Bullet Points was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a lot of discussion about blockchain at the moment, on many different platforms and from all industries. It has been hailed as a ‘quantum leap forward’, while others take a more negative view on what its impact will be; however the consensus is that its impact will be huge.

Despite all the attention that blockchain has been getting, there remains a large amount of confusion over what this ‘blockchain’ really is, and how it actually works. In this article I’ll answer each of the following questions:

• What is ‘blockchain’?
• How does blockchain actually work?
• Is blockchain the same thing as Bitcoin? (Hint: no)
• What are the different types of blockchain? How do they differ?
• Why do we care so much about blockchain?

What is ‘blockchain’?

It’s simple really: a blockchain is just a place where records are stored. For example, each record could be a monetary transaction — ‘Alice sent 3 coins to Bob’. The records are stored in such a way that they are ‘immutable’ — no one can maliciously edit them without being detected.

In most computer systems nowadays, records are stored in databases. These databases have rules outlining what information can be stored in each record, and further rules that specify the personnel and programs that are authorised to view and update the data stored. Blockchain works in the exact same way: there are rules laid out as to what information can be stored in each record, and then further rules specifying how this data is to be updated.

The two main differences between a blockchain and the ‘normal’ methods of data storage are:

• How the records are structured in storage, and
• The way that updates and additions to the data occur

These differences combined are what makes the records immutable — they will be explained below.

How does blockchain actually work?

The records in a blockchain are grouped into ‘blocks’. Each of the blocks holds some number, n, of records in the database. Every time n new records have been created, they are grouped together into a single block to be added as the newest block in the chain.

The way that these blocks are then chained together is using a special method called hashing. A function takes in a block, does some crazy merkle and hashing maths that you don’t need to understand just yet, and produces an output called a hash. It can be helpful to see this hash as a short summary of the block — changing the block even a tiny bit will change the hash that is produced. The hash of each block is then stored at the beginning of the next block in the chain. This effectively chains the blocks together, and means that no one can maliciously edit block x (as the hash of block x that’s stored at the beginning of block x+1 will no longer match up).

This data structure could be used to replace an existing database, allowing only a central company to add the updates to the end of the chain. For example, a bank could use a blockchain to store records of all monetary transactions to ensure the records cannot be changed. However, it is possible (and commonplace) to implement a blockchain in a ‘decentralised’ way, removing this central authority, and allowing the updates to be controlled by a larger group of individuals — thereby removing (at least some of) the power the central organisation holds.

The decentralised use of a blockchain can work as follows:

• A large group of individuals each store a copy of the blockchain
• Each new record to be added to the chain is broadcast to the group
• Once enough new records have been created, a group member proposes a new block, B, to the group
• Each member of the group separately decides whether B should be added to their copy of the blockchain. If a record within B is considered incorrect for any reason, then B can be rejected.
• If the majority of the group accept B, then it is added to the chain. If the majority of the group reject B, it is not.

The process of each group member checking the new block tends to be automated by a computer program that checks the validity of the block. For example, if ‘Alice sends 3 coins to Bob’ is a transaction within B, but Alice doesn’t own 3 coins, then the transaction is automatically noted as invalid and B is rejected.

This ‘group’ of individuals could be the entire network of individuals who use the system in question — or could be a smaller group. The larger the group, the more decentralised the network is considered.

Is there just one blockchain?

It is a common misunderstanding that blockchain=Bitcoin. That is when someone says ‘blockchain’, many people think of Bitcoin and are unaware as to what the difference is. Bitcoin is a currency, and it uses a blockchain to store the Bitcoin transactions that occur (every ‘record’ is a transaction e.g. ‘Alice sent 3 Bitcoin to Bob’). Within this blockchain, anyone in the world can choose to be a member of the group of individuals who keep the records up to date, thereby removing the need for a centralised banking authority.

The idea of blockchain was first published in the Bitcoin paper in 2008, and all other blockchains have stemmed from this moment, meaning that while Bitcoin may be the most famous application of blockchain in the world, it is certainly not the only one.

Are there different types of blockchain? How do they differ?

Since the first use of blockchain in 2008 in the launch of Bitcoin, blockchains have been used to track thousands of different items, on hundreds of different blockchains. These blockchains differ in many different ways, the most notable of which are:

• What’s being tracked on-chain — the ‘record’ system allows for any number of different items to be tracked on-chain. This could be real-life items such as your IKEA shipment, or digital items such as monetary transactions (Bitcoin) or execution of code (Ethereum).
• Private vs Public — who can see the blockchain? Is it available to anyone internationally? Or is it only viewable by a select group of people?
• Decentralisation — as mentioned previously, the size of the group who are authorised to update the data stored on the chain affects how decentralised the network is. This group could be one central individual/company who run and control the network, or as large as a network where anyone can take part in the decisions. Having a smaller group in control isn’t always a negative thing — it just depends on the situation in which is blockchain is being used.
• Consensus mechanism — the way in which agreement is reached within the network as to the exact order and contents of blocks being added to the chain. For example, if Alice and Bob both propose new blocks at the same time, the Consensus Mechanism of the network will outline rules to decide which block should be chosen.

Why do we care so much about blockchain?

The invention of blockchain brought something that has never before been possible to the world — a way of decentralising networks without a huge number of discrepancies or uncertainty as to what the current state of information is. This means that there is now the potential to remove the trusted and fee-collecting ‘middleman’ from a large number of everyday services such as banks, insurance firms and auction sites.

Blockchain-based systems are applicable anywhere information is recorded. However the immutability of blockchain records makes it especially powerful where that information is prone to hacks, fraud, or theft. Identity verification. Crowdfunding. Voting. Contractual agreements. These are just a few examples of industries in which companies are already developing new ways of doing business enhanced by blockchain technology.

Stay tuned for future posts that delve into some of the terms mentioned in this article and read about the projects at Token Foundry for more interesting examples of companies using blockchain.

0 to Blockchain in 5 minutes was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Brief History & Definition

In 1996, Nick Szabo first postulated his idea for smart contracts, as

“…a set of promises, specified in digital form, including protocols within which the parties perform on these promises.”

At the time, a fully decentralized “protocol within which the parties perform on these promises” did not yet exist. Certainly, several types of “contracts” or “agreements” are already built into existing systems. However, these systems did not encapsulate the methodology in which “parties perform on these promises” originally envisioned.

For example, one could say the system behind credit cards purchases contractually binds a user to pay for goods bought with the card. However, this agreement actually exists within several layers of siloed infrastructure. That is, if I do not pay my credit card bill, a separate collections agency will rely on the data held by the credit card company to resolve the issue along with any supplemental information that I can provide. In other words, as there is no shared repository of data or transactions with which to observe the contract, the collections agency must rely on the data provided by both parties in a disagreement to resolve the issue .

As blockchain technology evolved, thought leaders connected the idea that if a shared digital ledger of information, logic, and value was available, smart contracts could exist as intended. Although not the first to do so, Bitcoin provided a decentralized system of purely digital value. Seeing Bitcoin as a uniquely transactional system , the creators of Ethereum imagined that if Turing-complete programs that stored value and information were developed on a blockchain, then smart contracts would flourish. Hence, the Ethereum smart contract system was born as written programs, operating within the constraints of the Ethereum protocol to ensure all parties interacting with the smart contract act in accordance with these codified “set[s] of promises.”

Now, within the Ethereum ecosystem, smart contracts provide a way for users to form agreements and execute logical code in an economy that is designed with incentives and deterrents to entice individuals to interact in a benevolent manner.

What Can Smart Contracts Do?

To begin, we first must understand that smart contracts are, in fact, a type of account, much like an account that we might use out of an exchange to purchase Ether or tokens, typically called an externally owned account as opposed to a smart contract account . This “account” designation for smart contract means that similar to an externally owned account, a smart contract can hold Ether or tokens.

In addition, smart contracts hold storage, which includes code and information. As expected, the code within a smart contract can be anything within the constraints that the programming language, Solidity, allows, or any other language that will compile properly to work with the Ethereum Virtual Machine allows for that matter. Storage refers to the ability of smart contracts to store information. For example, an ERC20 token contract stores each user’s individual balance of tokens. However, to store something like an entire document within a smart contract is currently impractical and very expensive, which is why most smart contracts store the minimum amount of information required for a contract. Consequently, instead of attempting to store several pieces of information within a smart contract, many projects have opted to referencing a hash of a document or file, instead of the entire file itself.

Now, three years into the Ethereum ecosystem, the community has developed several standards with which smart contracts are built. The most well known application has been that of token contracts such as the fungible ERC20 tokens or non-fungible ERC721 tokens. These tokens store information about the specific token owners, token transfer abilities and other information. Other applications use smart contracts as a type of verification service. For example, with the Uport system of smart contracts, a user can register their identify and further use that verified identity in other applications. Further along the lines of verification, industries are using smart contracts to verify the origin and production process of various products through initiatives such as Viant.

What Can Smart Contracts Not Do (Yet)?

As with any nascent technology, common overreaching assumptions exist. We have already mentioned one common misconception regarding smart contracts — Ethereum smart contracts do not easily or cost-effectively hold large amounts of data.

Another common misunderstanding regarding the capabilities of smart contract is their autonomy or lack thereof. In other words, smart contracts do not exist with any autonomy or ability to create their own transactions. An externally owned account must initiate a transaction — a small caveat to this is that once an externally owned account initiates a transaction a smart contract may call another smart contract. However, the transaction will always ultimately start via an externally owned account. Now, there are services in which an externally owned account may be programmed or timed to execute a certain transaction when conditions are met; however, this transaction again will not initiate from the smart contract itself.

Along the lines of autonomy, another common misconception regarding smart contracts is the ability to respond to data. As mentioned, a change in a smart contract must be initiated through an externally owned account. For example, say we wanted to watch the price of oil, and when it dropped 5%, we wanted to update pricing. There are no immediate, available methods with which a smart contract can watch or query information outside the Ethereum blockchain. Other services must be brought in to accomplish that goal of watching external data and responding to it on Ethereum.

Your First Solidity Smart Contract

As a simple starter, let’s build a smart contract in which we can store a number, send Ether to the contract and specify who we want to withdraw that Ether. You can follow along in Remix — the Solidity IDE that allows developers to interact with the mainnet, testnets, and a built in Javascript Virtual Machine that mirrors running a local Ethereum blockchain. The code is also posted here.

First, at the top of our smart contract we must indicate what compiler version we would like to use. Solidity is a compiled language. This means before we interact with the code, it must be compiled into bytecode to be read by the Ethereum Virtual Machine. To do this, we use:

pragma solidity ^0.4.24;

This tells the compiler to use the 0.4.24 version — the latest, most stable to date at the time of this writing. The ^ tells the compiler to use any compiler version 0.4.24 or higher and is to be used only in development stages. Whenever a contract is ready to be deployed to the main net, best practice is to remove the ^ so that an exact, expected compiler version is utilized.

Next, we initialize our contract by naming it, and we can add the first global variable that we would like to store, our number:

contract FirstSmartContract {
      uint256 public theNo; 
}

Above we initialize a global variable theNo in which we will store our number. It will be an unsigned integer of 256 bits, to put it simply, it’s a positive number. Notice that we denote this variable with the visibility specifier public . Using this specification, we automatically receive a “getter” function in which we can get the value of theNo from the contract. A public variable can also be access via inherited contracts as well.

There are other visibility specifiers we could have used, which include private and internal . The private specification is a bit of a misnomer. As private the variable will still be available for anyone examining the blockchain to see; however, the automatic getter function that we received with the public specifier will not be generated. Unlike the private specification, the internal specification, allows a variable to be accessed only from contracts that inherit from it but similarly there is not getter function provided.

Now, as we said in the beginning, we would like to be able to set this number, so we can set up a function as the below to accomplish that goal:

contract FirstSmartContract {

      uint256 public theNo; 
      
      function setNo(uint256 _theNo) public {
            theNo = _theNo; 
      }

}

The above function setNo() takes in a uint256 _theNo and assigns it to our global variable theNo. Up until this point, if we had used the getter function to set what number was stored by theNo, we would have seen 0 — this is a universal default of Solidity, unassigned variables default to 0 value.

As our variables had visibility specifiers so do functions. A public visibility specifier allows any externally owned account or other smart contract to make a call to this function. Additionally, calls to a public function can be made from within the contract itself from other functions as well. Similar the variable visibility specifiers, the private specifier only allows the function to be called within the contract, not any contracts inherited, as in another function within the contract would be the other way to call this function. Internal functions may only be called within the existing contract or from inherited contracts. There is also an external visibility specifier in which functions can only be access externally, not internally within the contract.

Now, recall that we wanted to be able to send Ether to this contract and assign it to another address to withdraw. Let’s see some additions that will allow us to do that.

contract FirstSmartContract {

      uint256 public theNo;
      mapping (address => unit256) public balance; 

      function setNo(uint256 _theNo, address _receiver) 
         public 
         payable 
      {
            theNo = _theNo;
            balance[_receiver] = msg.value; 
      }
}

First, we have added a mapping in which we take an address and map that address to a uint256, which will be a balance of the named address in our case. Again, we have used a public visibility specifier so that we will gain an automatic “getter” function.

Looking to our updated setNo() function, we have added an additional parameter for an address _receiver or the address we will choose allow to withdraw the Ether sent to the contract within the contract using:

balance[_receiver] = msg.value;

This maps the address of the _receiver to the amount of Ether sent to the contract. Msg.value is a global variable available in any contract function, which refers to the amount of Ether sent in the transaction. Note that the amount of Ether will actually be denominated in Wei — one Ether is 10¹⁸ Wei.

Now, we want to allow the _receiver to withdraw the Ether in the contract. In order to do that, we implement the following function:

function getEth() public {
    require(balance[msg.sender] > 0);
    uint256 amount = balance[msg.sender];
    balance[msg.sender] = 0;
    msg.sender.transfer(amount); 
}

This is our first view of a require() statement. Require() statements in Solidity allow us to specify certain conditions that must evaluate to true in order to allow the function to execute. Should the conditions within a require() statement evaluate to false, then the function and all actions prior to the require() statement would be reversed or reverted. By reversed or reverted, we mean that all state changes would be “cancelled” and return back to their original state prior to the transaction.

Here, we have required that the account sending the transaction have some Ether assigned to it in order to proceed with the withdrawing — as there is no sense in allowing an address with zero Ether assigned to withdraw zero Ether.

Again, msg.sender is a another global variable available in Solidity functions that refers to the account that sent the transaction — note that this can refer to a smart contract account as well, should the transaction be sent from a smart contract. In our case, if the msg.sender does have some Ether assigned to their account, we assign that Wei amount to the local variable amount. To ensure that they do not attempt to withdraw more Ether than their allotted amount, we now set their mapping to 0. This type of pattern ensures that we are not vulnerable to re-entrance attacks — a much larger topic that is discussed in detail here.

Lastly, we use the global function transfer() to send the amount to the msg.sender, which has uses the form:

addressToSend.transfer(amountToSendInWei)

An important feature of the transfer() function is that if it is unsuccessful, it will revert, much like our require() statement. Thus, if for whatever reason, transfer() is unable to execute, the msg.sender will not lose their assigned Ether as balance[msg.sender] = 0 will revert and return back to the original state.

All together, we have a simple contract that allows us to:

1. Set a number in the contract.
2. Send Ether to the contract and assign it to another address to withdraw.
3. Withdraw any allocated Ether from the contract to a certain address.

The full code is below and can be found here.

contract FirstSmartContract {
    
    uint256 public theNo;
    mapping (address => uint256) public balance; 
      
    function setNo(uint256 _theNo, address _receiver) 
        public 
        payable 
    {
        theNo = _theNo;
        balance[_receiver] = msg.value; 
    }
      
    function getEth() public 
    {
        require(balance[msg.sender] > 0);
        uint256 amount = balance[msg.sender];
        balance[msg.sender] = 0;
        msg.sender.transfer(amount); 
    }
      
}

We hope this brief introduction has allowed you to understand a bit more about where and how the idea for smart contracts came together. Smart contracts truly enable an entirely new economic system through the use of Ether, tokens, and decentralization verification of data. There are many more nuances to understand in order to build effective, scalable, and secure smart contracts, and we intend to dive into those aspects in further publications.

What is a Smart Contract? was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Token Foundry, we use dynamic pricing to let the demand for a token and the token sale performance dictate the final price of each token– rather than the token seller setting the price themselves.

In other industries or use cases, dynamic pricing might seem counterintuitive. But, for the time being, we feel this is the simplest and fairest token pricing structure for purchasers. In addition to every purchaser paying the same price per token, another significant benefit of dynamic pricing is that if the sale target (hard cap) is not reached, purchasers get a better token price than originally anticipated.

For newcomers to token sales, we have broken down dynamic pricing to help you understand why we believe it is the fairest and simplest way to set the price of tokens.

Dynamic Token Pricing Formula

(Total USD$ amount of tokens purchased) / (Number of tokens being sold) = Final Token Price

That’s really it. At the end of the sale, we just take the total USD$ amount of tokens purchased in the token sale, and divide it by the total # of tokens being sold, which is a constant (more on that below). Let’s take an example token sale to fully understand how it works both before, during, and after the sale.

Example Token Sale:

• Total Token Supply: 1 Billion
• Tokens Being Sold in Sale: 500 Million (50% of Total Supply)
• Sale Target (hard cap): $20 Million

For all token sales on Token Foundry, all tokens being sold in the sale (e.g. 500 Million) will be distributed to purchasers regardless of amount raised. For example, if the $20M sale target (hard cap) is reached, the 500M tokens being sold will be distributed proportionally amongst the $20M worth of purchasers; if only $10M worth of tokens are purchased in the sale, the 500M tokens being sold will be distributed proportionally amongst the $10M worth of purchasers; if only $5M worth of tokens are purchased in the sale, the 500M tokens being sold will be distributed proportionally amongst the $5M worth of purchasers. This is what enables dynamic pricing to work.

Initial Token Price Calculation:

($20M) / (500M tokens) = $0.04 per token (max price)

We intentionally show the max price before and during the token sale so purchasers can see the worst-case-scenario price they would pay for each token. This enables them to make an informed decision on how many tokens they want to buy, and the maximum it’s going to cost them (in terms of USD$). After the sale, the actual price is adjusted based on the above formula and the final results of the token sale.

For other dynamic pricing models, vendors might show a moving price per token which would rise throughout the sale. We prefer to show the max price as a constant during the sale, to avoid misleading early purchasers who thought they would receive more tokens than they end with if, for instance, they purchased tokens early and then the hard cap for the sale is reached.

The max price is also useful for being able to properly evaluate other factors such as network value. Even if you don’t care about network value, it’s important to be informed and understand what it is and how it can potentially impact the future price of tokens you are purchasing.

As it relates to token pricing, a higher token price means a higher network value and vice versa. As a general rule of thumb when purchasing tokens, a lower initial network value for a token is typically beneficial for the buyers and users of that token. With dynamic pricing, if the sale target (hard cap) for a token sale is not reached, both the token price and network value of the token will be lower than what it would have been had the sale target had been reached, which most token buyers would consider to be a good thing. Surprisingly, a token sale not ‘selling out’ is actually beneficial for the people who bought tokens in that token sale. Token purchasers should keep this in mind when deciding to buy tokens in a token sale.

What Happens During the Sale When Buying Tokens?

As mentioned above, before and during the sale, we use the max token price for purposes of calculating the maximum (in terms of USD$) you would need to pay in order to purchase the amount of tokens you want. The ‘total amount owed’ is the amount you send to the token sale contract when completing your purchase.

Example 1: Purchasing 10,000 tokens

($0.04) x (10,000) = $400 (total amount owed)

Example 2: Purchasing 50,000 tokens

($0.04) x (50,000) = $2,000 (total amount owed)

What Happens After the Sale Ends:

Using the Dynamic Token Pricing Formula shown above, once the sale ends, we take the final USD$ amount of tokens purchased in the sale, and divide it by the total number of tokens being sold (500M), which as explained above will always be the same amount (500M) regardless of the USD$ amount of tokens purchased.

Final Token Pricing:

Example A: $20M worth of tokens purchased in the sale (hard cap reached)

($20M) / (500M tokens) = $0.04 per token

Example B: $10M worth of tokens purchased in the sale

($10M) / (500M tokens) = $0.02 per token

As you can see, if less money ends up coming into the token sale, those who did purchase tokens in the sale benefit by getting a better price per token.

So How Many Tokens Do I End Up Getting?:

Once the final token price is determined, you will receive an amount of tokens equivalent to the USD$ amount of tokens you purchased in the sale (ex. the ‘total amount owed’ from before) divided by the final token price. So using the different token amounts and final token pricing examples from the two sections above, here are a few different scenarios.

Example (1) + Example (A): USD$ Amount Purchased: $400; Final Price: $0.04 per token

($400) / ($0.04) = 10,000 tokens (amount received)

Example (1) + Example (B): USD$ Amount Purchased: $400; Final Price: $0.02 per token

($400) / ($0.02) = 20,000 tokens (amount received)

Example (2) + Example (A): USD$ Amount Purchased: $2,000; Final Price: $0.04 per token

($2,000) / ($0.04) = 50,000 tokens (amount received)

Example (2) + Example (B): USD$ Amount Purchased: $2,000; Final Price: $0.02 per token

($2,000) / ($0.02) = 100,000 tokens (amount received)

In summary, dynamic pricing benefits purchasers by allowing demand for the token and token sale performance dictate the price of the token, rather than the issuer setting the pricing themselves. It’s our goal to attract large numbers of value-add purchasers to networks, as decentralized networks are reliant on actual usage and network effects for their success. Hopefully this post has helped to pricing, since it’s important for all those participating in our token sales and the token economy to understand.

Explaining Dynamic Pricing: The Simple and Fair Pricing Structure We Use For Token Sales was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s no secret these cities are a hotbed for blockchain technology and ideology. Genesis Market Insights recently ranked Asia as the fastest growing market in the global blockchain market (which they predict will quadruple by 2023).

From conference halls to start up hubs, the buzz of anticipation for this growth was palpable. The Token Foundry team was lucky to attend a number of larger industry-advancing events, as well as intimate dinners with some of the top thought leaders and investors in the space.

By the Numbers

Over 22 days…

• Distance travelled: 24,520 miles
• Time spent on flights: 55.5 hours
• Conferences attended: 3
• Co-hosted events: 15
• Other events attended: 22
• Meetings: 76
• Twitter impressions: 412,500
• Twitter engagements: 1,191

In case you’re getting FOMO, we pulled out a number of highlights from across the tour so you can catch up on the best of what went down.

Trip Highlights

Singapore, July 1–3

Tokyo, July 4–7

Hong Kong, July 8–11

Beijing, July 12–15

Seoul, July 15–18

Shanghai, July 19–22

Our consensus is that you can expect great developments coming out of Asia in blockchain, and we’ve learned a ton having our finger on the pulse for a few weeks.

For other token and blockchain-related news, follow Token Foundry on Twitter.

5 Countries in 3 Weeks: Token Foundry’s Tour Across Asia was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

We recently released our Token Foundry Standards for selling tokens and launching networks, and last week we launched registration for FOAM’s upcoming token sale on July 31. We wanted to highlight some of the stats so far to show how our new framework is going.

2,135 registrants and counting

When we launched our Token Foundry Standards, one of the main concerns we heard was that a thorough vetting process during registration would deter people from registering for token sales. These registration numbers should alleviate that concern and show everyone that there are plenty of prospective token purchasers out there willing to complete the process to participate in the networks they support.

~25% of registrants have failed the questionnaire

We require all token sale registrants to answer questions proving they understand what they are buying– and that they actually have intent to use the tokens they are purchasing for their intended purpose.

So far, 25% of the people who have tried to register for the FOAM sale have provided answers that indicated they either don’t understand what the FOAM token is, or that they don’t intend to use it (i.e. speculators). Those people are now blocked from being able to participate in the FOAM sale.

The remaining 75% of registrants did provide proper responses indicating the breadth of their knowledge and their intent to use the FOAM network. We believe this will create a base of token holders for FOAM who will actually add value to the network, a point we feel is critical to the success of the network– especially at the launch stage. When a decentralized network starts strong, with thousands of informed and dedicated users, it is positioned to thrive in the long term. It’s not just an experiment.

~50% of registrants requested $1,000 or less worth of tokens

We love this. We feel it’s important to try to have a wide distribution of tokens, and as many informed token purchasers as possible. We want participants who are actually interested in using the network and adding value to it.

Selling all your tokens to a few large purchasers isn’t a great strategy to encourage broad network usage and adoption. It’s great to see smaller purchases being represented in the registrant base.

Large purchasers are leaving some encouraging responses

Sale registrants who request an amount of tokens worth over $10,000 are required to provide additional information explaining the reason for their purchase, and how they plan to use the amount of tokens they are purchasing. Some of the explanations are super cool. Below are a few excerpts:

I have already planned out areas of the UK where I have contacts that will allow me to place hardware devices. I have been in the crypto space since 2011, I run a crypto fund as a job and I feel that FOAM tokens are the best example of a utility token. I look forward to helping build the FOAM ecosystem here in the UK.

—

We are a community based in Moscow that strongly trust in FOAM project and is willing to deploy a network in Russia in following years. Me and my partners follow the info updates from FOAM and have potential technical resources to go on with hardware stage of the project.

—

I am hoping to lead verifying location points in New Zealand given I think there will be limited users here to begin (in this geographic location).

—

We are planning to set up check points in the state of Illinois, which would cover Chicago, Rockford and the surrounding suburbs.

—

I am interested to become cartographer to add many POI as well as signaling for the GCC region. In addition, run a zone anchors in my city with my friends and family.

—

…we have began to lay out a map of Victoria determining locations we are able to provide anchors and POIs. I aim to provide as widespread area of coverage as possible in the entire north and central area of Melbourne city.

—

I intend to stake most of my tokens to set up geographic points of interest throughout Lisbon and other places I visit.

100% of purchasers have to prove use

Before being able to transfer or resell any tokens, all token holders have to “prove use” proportionate to the amount of tokens they buy on the token sale. All successful registrants have fully acknowledged and accepted this. Proving use is done trustlessly, so registrants can’t just say they are going to use the tokens — they actually have to prove it.

Thank you for appreciating!

We’ve been thrilled with the public response to our Token Foundry Standards and the FOAM registration process so far. Here are a few we really liked:

Spencer Noon 🕛 on Twitter

Just went through the @foamspace registration process on @tokenfoundry and I'm pumped up! + all investors can participate (not just accredited) + purchasers have to prove they're actually using the protocol + protocol literacy is tested This is the future of token sales.

Neeraj Thakur on Twitter

Another brilliantly executed ICO experience by @foamspace + @tokenfoundry 💯🙂 h/t @frothcity @katya_zavyalova @kejace

Crypto Bobby on Twitter

Token Foundry is doing some pretty cool stuff with token sales, and I really hope it's the way the industry trends. Investment opportunity not based on accreditation status, but on protocol knowledge and actual utilization. https://t.co/vQDbDnqbRp

bitbitbit on Twitter

@twobitidiot @tokenfoundry @foamspace Was wondering what this was about until I checked my email lol. I agree @tokenfoundry registration was really nice. Future of ICOs?

Simon Waddington on Twitter

The Token Foundry registration process and it was one of if not the most thorough I've completed. Ditto for the @foamspace registration on TF which went a long way to requiring proof of brain and understanding of risk, restrictions, and participation. This is double plus good! https://t.co/M8TqPMyQnH

We love hearing from the community, so feel free to reach out with questions or to share your thoughts and feedback at any time. We will continue to iterate, and develop products and features that are helpful to both token issuers and token purchasers. We’ll be incorporating user feedback directly into that process.

How Our Standards are Working: Stats from the FOAM Sale Registration was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

Market design is an emerging economic field concerned with making existing markets better and inventing new ones through good engineering. It investigates the best ways to ensure that marketplaces allow everyone to come out ahead, and has already resulted in life-saving inventions such as kidney exchanges, solutions to tough problems like school choice, and tools to ensure fair and agreeable job placements.

Another emerging technology is the digital token, a tradeable unit customized with software capabilities provided by globally-distributed programs known as smart contracts. Thus far, the use of many tokens has been weighted towards speculative activities by investors, but there are far more interesting properties than speculation worth examining through the perspective of market design.

When infinite demand meets finite supply, there is scarcity, but with thoughtful resource allocation, happiness remains a distinct possibility.

Principles of Market Design

In The Handbook of Market Design, Vulkan and Roth introduce three important principles for the successful engineering of markets: sufficient thickness, limited congestion, and safety.

1. Thickness: A healthy market must have enough participants willing to transact and create benefit through trade, and to further attract more participants. For example, buyers prefer to have access to many sellers, and vice versa. Generally, stores and shoppers are not interested in dead malls.
2. Congestion: The market must mitigate traffic jams to enable the free flow of transactions. Though this may be caused by an increase in thickness, it must be managed so that all participants have sufficient time to consider their options, or they may be forced to act on incomplete information. For example, many women on dating websites receive more solicitations than they have time to evaluate, resulting in a poor experience for all participants.
3. Safety: Participants must feel safe to transact on the marketplace and to reveal their true preferences. Without proper safety, participants may wish to transact outside of the market or attempt to “game the system” which adds a barrier to entry for other participants. Trades may become too encumbered with uncertainty to occur; for example, refusal to sign a contract or lack of enforceability significantly contribute to deal friction.

Additionally, certain markets must operate under the constraint of repugnance: negative social sentiments about certain activities that may harbor no direct harm to the willing participants, such as prostitution or the sales of kidneys.

Furthermore, through the use of experiments, it may be possible to test certain market designs without paying the full upfront cost of assembling and bootstrapping a marketplace.

Why Tokens?

Blockchain technology may be the excitement of the decade, with initial coin offerings reaching record levels and many businesses incorporating blockchains in their products to capture new opportunities. One popular pattern is the digital token. Like bitcoin, tokens have created scarcity in the digital world, where the marginal unit costs of production typically race towards zero.

Combined with smart contracts, tokens allow for credible and meaningful representation of metered resources in digital form, including voting rights, licenses, land rights, securities, and physical assets. As public blockchains gain acceptance as legitimate global sources of truth, the costs of representing real-world ownership in digital form become smaller when built on this common infrastructure. This translates to lower transaction costs, which will in turn accelerate e-commerce.

Tokens and Network Value

Tokens can belong to networks, which have valuations. A network is the collection of the technology, infrastructure, processes, and network effects that drive a specific microeconomy. For example, the collection of Bitcoin users, miners, nodes, and developers form the bitcoin network. Similarly, the respective components for Ethereum constitute the Ethereum network.

Tokens can be engineered so that their prices are to some degree tied to the network’s value. This serves as an important input to and output from network behaviors. Consider the Bitcoin network, in which the price of one bitcoin acts a lever for mining activity; because mining rewards are fixed in bitcoin, an increase in the USD price of one bitcoin will also increase the attractiveness of mining activities, and vice versa.

How can tokens help build marketplaces? Using the principles above, it may be possible to identify several mechanisms in which tokens serve as worthwhile inputs.

Principles of Market Design Applied to Tokens

Tokens can be used to help markets by increasing thickness, reducing congestion, and providing safety. Instead of thinking about if a system should require staking, it may be more meaningful to ask if a system’s users require adequate market safety to comfortably transact. Rather than blindly allocating mining rewards, a network can be tasked to achieve specific levels of network activity, or market thickness. Web developers do not write their programs in low-level assembly language. Projects too can benefit from higher-order tooling for expressing and achieving their ultimate goals.

Increasing Thickness

Mining

Projects with tokens will often set aside a reserve of tokens for “mining,” an activity which aims to reward behaviors that strengthen the network. In the Bitcoin network, the mining activity consists of solving cryptographic puzzles to provide transaction settlement capabilities to users of the currency. The creator of Bitcoin observed that early miners take outsized risk on their resource investments for a fledgling network, and thus should stand to receive an outsized reward for their participation. Thus, the rewards for mining in the Bitcoin network diminished over time.

By disproportionately rewarding early adopters to spur network growth at the most critical junctures, a network can provide fair incentive to its participants scaled to the impact of their contributions towards growing a strong network economy. When the reserved portion of tokens are completely mined, the project is expected to have taken flight and able to sustain itself off of transaction fees alone. To put this another way, mining can be used to increase market thickness by shepherding network effects to sustainable steady states.

Partnerships

Strategic partnerships with organizations or companies in relevant industries can drive early adoption and bootstrap network effects. For example, in Uber’s partnership with American Express, the ridesharing company provided credits to Amex card holders to attract new users while Amex could offer more benefits to its existing users. Likewise, some projects send preallocated or newly-minted tokens to entice network participation. Networks that inflate their supply to build partnerships should only do so if the added value of the partnerships exceeds the cost of dilution across finances and control.

Referral Bonuses

Many P2P marketplaces pay users to refer new users if the prospective increase in network value surpasses the payment amount, as was pioneered by PayPal in the early 2000s. Reserved tokens can serve this purpose too, but at even steeper incentives as rewards may then scale to the benefits that the referrals bring to the network. One important concern that must be addressed is sybil attacks, in which attackers create many new fraudulent accounts to collect referral bonuses, thereby sapping the network of its resources without delivering value.

Reducing Congestion

Transaction Fees

Many token economies require the payment of network fees in tokens. When token prices are correlated to network value, it is more expensive to run the same transaction on a more valuable network. In general, popularity drives network value, and the resulting increase or decrease in token price has a self-regulating effect on the congestion of transactions.

Those more willing to transact will offer higher fees to convince the network to give their transactions preferential treatment. In return, the higher fees may attract more transaction processors to eventually lower the fees. This works well when the value of a network activity to its participants is scaled to the fee they must pay, well-aligned with pricing theory — more use means more cost.

In the Ethereum blockchain, fees are paid in Gas per computation step taken in smart contracts, penalizing large programs while encouraging efficient programming. This fee structure is used to meter a rival good: the network has limited computational capacity, as all compute nodes on the network must run every smart contract, effectively limiting the network computational capacity to that of a single node. Scarce resources must be rationed, and fees can serve as mechanisms to do so.

In another example, Bitcoin transaction fees during the craze of late 2017 climbed as high as $37 per transaction. High prices have done a lot to discourage frequent or low-volume transactions which would further congest the network. Whether this is considered a market failure or success depends on the goals of the network, but it is wise to remember that mechanisms do buckle down and sometimes fail to deliver on their key objectives. The Bitcoin community is very familiar with the political turmoil and strife that occurs with differing high-level network goals held by different camps of participants.

The lens of congestion reveals an open problem in today’s prominent decentralized networks: “full nodes” host and share the entire transaction histories of the network for free, yet they are critical to network performance and consistency. While there are incentives for the operation of full nodes, they are often not directly financial and difficult to model. For example, due to growing industry interest and the rapid pace of adoption, the Bitcoin network can take several hours to weeks for a full sync on commodity hardware. Furthermore, transactors pay once and forever replicate to all full nodes that join the Bitcoin network.

Grading transactions, metering bandwidth, and charging access fees are ways to mitigate congestion by leveraging market forces. They can help important transactions enjoy more consistency, unlock premium performance for those willing to pay, and create new revenue streams for node operators. They can also coexist with a free basic access layer to encourage widespread adoption.

Membership Deposits

When denominated in the native token, membership deposits can track the network value and provide scaling barriers to entry to discourage low-quality listings. With the assumption that membership quality is correlated with ability to put up entry fees, a network with rising value will have higher quality membership.

Providing Safety

Governance

Businesses love stability: infrastructure, property ownership, and functioning legal systems are important catalysts that firms need to thrive. If an enterprise were to leverage open-source technologies as its core building blocks, it would be at the whim of the project maintainers.

Tokens can help businesses and individuals shape open-source development efforts through voting and similar mechanics. Because businesses have an interest in maintaining their underlying infrastructures, there is value in participatory rights as they can be used to secure a long-term development roadmap.

Smart Contracts

When tokens are augmented with smart contracts, they provide many computer-enforced guarantees around deal mechanics that must usually be drafted into legal contracts. For example, a good faith deposit implemented with a smart contract can be confirmed by all parties that the funds will be transferred to the payee upon deal expiry.

Attestations

Attestations are beliefs about reality that can be accounted. When they are used on a blockchain, they typically take the form of a digital reference to more concrete body of evidence. Examples of blockchain attestations:

• A signed digital reference to an image of a state-issued license for conducting Know Your Customer (KYC)
• A website address to an API on an official manufacturer’s website which provides confirmatory responses to valid serial numbers, along with a cryptographic proof of the device’s claimed serial number
• A phone number and business hours, regularly validated by reputable and independent 3rd parties
• A signed digital reference to a scanned PDF proof of $1MM in liability insurance

Attestations improve market safety by giving participants more knowledge about their prospective counterparties and therefore seeding trust. People feel safer dealing with people they can trust.

Staking

Staking requires network participants to put up safety deposits that may be arbitrated in a dispute. An arbiter may review a transaction and decide to award damages to a wronged party, paying from the safety deposit. Along with a safety deposit minimum, the network can effectively evict bad actors. When participants have “skin in the game,” they are less likely to act erratically and put more thought before violating rules.

Conclusion & More Resources

Market design is a powerful paradigm that can help create new online marketplaces in a sustainable fashion. Tokens should exist to serve important purposes or they will only add friction to participation. Through the pillars of market thickness, congestion, and safety, we can orient tokens, smart contracts, and game-theoretic mechanisms towards higher goals.

The best place to get started in market design is Alvin Roth’s very accessible book, Who Gets What and Why. A more technical dive can be found in The Handbook of Market Design by Nir Vulkan and Alvin Roth, which goes into specific mechanisms such as auctioning and voting. Other books related to market design include:

• The platform, which deeply incorporates market design, is one of three pillars in Brynjolfsson’s Machine Platform Crowd.
• Matchmakers by Evans explores the specific benefits to customers of online marketplaces and also how their founders have learned to bootstrap new ones.
• The Economics of E-Commerce by Vulkan is now a decade and a half old, but even more relevant today. It gets into the nuts and bolts of search costs and the varying degrees of commoditization in online markets.

Market Design with Tokens was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Token Foundry team is once again on the move. We just wrapped up our European tour visiting all of you throughout Dublin, Paris and Switzerland. Now we are heading east to Asia!

Token Foundry will be attending a number of summits, conferences and meet-ups including TokenSky, Rise, and Beyond Blocks. Check out all of the events we’ll be attending below, and be sure to drop us a line if you’re there.

Singapore

July 1–3
 — 
Token Foundry x Ethereum Summer Meetup
July 3
We’re opening the doors of The Blockchain Hub to host a gathering with some of our top projects focused on the future of decentralized token-powered networks. Join us for founder talks, great food and beer and an evening of high quality networking with others in the Ethereum ecosystem.

Guests of this gathering will be able to hear from founders of Token Foundry’s hottest projects including Weeve and Colendi. We’ll talk about how token models are changing the world and the way we interact.
RSVP

The Legal Challenges of Token Design
July 3
Join the Token Foundry and Norton Rose team for an afternoon gathering packed with personal insights and discussion about the Law & Crypto Assets and where the industry is heading.
RSVP

Tokyo

July 4–7
 — 
TokenSky
Our founder, Harrison Hines, will be speaking on a panel at TokenSky about the mission and services of Token Foundry.

Token Engineering Meetup
July 5
Join the Token Foundry and Norton Rose team for an afternoon gathering packed with personal insights and discussion about the Law & Crypto Assets and where the industry is heading
RSVP

Neutrino x TF x Ethereum Tokyo Meetup
Check back later for the invite.

Hong Kong

July 8–11
 — 
RISE Hong Kong
Join us at one of the largest tech events in Asia, RISE, where our founder will be speaking on properly designed token-powered networks.

Token Foundry + Tokenomia Showcase
July 9
Token Foundry and Tokenomia are taking over Nakedhub Sheung Wan to host a Monday meetup about the future of decentralised token-powered networks. Join us for token design talks, drinks and canapés and an evening of high quality networking the night before RISE HK officially kicks off.
RSVP

Beijing

July 12–14
 — 
We’ll be meeting with a variety of blockchain projects in the Beijing metropolitan area over these three days. If you’re in Beijing, drop us a line.

Seoul

July 15–18
—

Blockchain Blocks Summit
July 17–18
This summit is one of the premiere conferences specific to blockchain technology and policy, and labels itself as “focused on the most controversial topics in the current blockchain space.” Prepare for in-depth discussions with visionary speakers.

TF x Chain Partners Seoul Night
Check back later for the invite.

Shanghai

July 19–20
 — 
We’ll be hosting a blockchain summer soirée, and developing partnerships with an array of blockchain-related companies in Shanghai.

We’re on a mission to power the decentralized future with properly design tokens and their respective networks. Come meet us at any of these events, and learn from some of the amazing projects we’re working with to build that future.

Events Roundup: We’re Headed Across Asia was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.

Purchasing anything online comes with an element of risk. As a consumer, you are expected to perform a cost-benefit analysis of completing a transaction. Is your purchase secure? Can you guarantee receipt of goods purchased, in the state you were promised?

When considering conducting a purchase on a decentralized network such as Ethereum, one might feel an added sense of caveat emptor. However, rather than having a third party intermediate, we design and build smart contracts that allow purchases to happen securely and fairly.

Smart contracts, used in this way, are protocols for ensuring transactions happen credibly at the time of purchase. We add a feature to our smart contracts called ‘data payloads’, to block bad actors from transacting on Ethereum and thereby building a stronger, more fair network for everyone.

This post is intended to provide insight into how we design our smart contracts, and specifically why we require a data payload by default.

Components of an Ethereum token sale

Let’s begin with the core concept: constructing a transaction to purchase tokens during a sale. I’ll begin by explaining the different fields included in a transaction, along with why they are required when participating in a Token Foundry sale. (If you are experienced with purchasing tokens on Ethereum please feel free to skip ahead to where I describe how we construct our data payload.) If you are just learning though, this should help provide you with greater insight into the inner workings of Ethereum.

First of all, what is gas?

Throughout this article, you’ll see me reference something called gas. Gas is the unit used to measure the computational work required to complete a transaction. You can think of gas the same way you think about electricity. For example, the amount of energy required to run the same light bulb each day will be constant, but the cost per unit of energy each day will be different. This cost varies depending how much demand there is for energy at a given time. The same concept can be applied to gas. It will take the same amount of gas to complete the exact same transaction every day but, depending on the network load, the cost per unit of gas could be drastically different.

{
“from”: “0xb60e8dd61c5d32be8058bb8eb970870f07233155”,
“to”: “0xd46e8dd67c5d32be8058bb8eb970870f07244567”,
“gas”: “0x76c0”, // 30400
“gasPrice”: “0x9184e72a000”, // 10000000000000
“value”: “0x9184e72a”, // 2441406250
“data”: “0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675”
}

Refrence: https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendtransaction`

The fields of a transaction

FROM

This is the Ethereum address that the transaction is being sent from. In the case of a token sale, it must be the address you’ve registered with on the Token Foundry platform. This will be the address you are purchasing from and, at the end of the token sale, this will also be the address that has access to your tokens.

TO

This is the Ethereum address that the transaction is being sent to. In general, this is the account or smart contract you are transferring money to, or calling a function of. In a token sale, this is the sale’s contract address

GAS

(Optional field, but recommended.) Also known as ‘gas limit’. This is the maximum amount of gas you are providing to execute your transaction. This will default to a specific value unless defined otherwise.

GAS PRICE

(Optional field, but recommended.) The amount of ether you are willing to pay per unit of gas, this is generally input as either price per Wei or per Gwei (these are subunits of ETH). If you wish for your transaction to be confirmed faster, you should submit a higher-than-average gas price. This will default to a specific value unless defined otherwise.

Value

The number of ETH you are sending to the TO address. Be sure to check the denomination before sending.

Data

When sending a transaction on Ethereum to a smart contract, the contract will have access to this data field. The data includes the first 4 bytes of the hash of the function’s signature, followed by the ABI-encoded parameters as an abstraction. In simpler terms, this is the function in the contract you are calling, along with the required parameters you are passing in.

The data payload

If you’ve participated in previous token sales you may have noticed that they don’t require you to include a “transactional data” field or a data field.

The reason Token Foundry requires purchasers to include this string is because in that piece of data, we verify a number of pieces of information about the contributor themselves. This includes:

• The address you are allowed to send ether from
• The limit of ether you are allowed to contribute
• Whether you have passed the project’s questionnaire
• Whether you have KYC’ed with Token Foundry
• The actual signature generated by Token Foundry’s whitelist admin to verify that you are allowed to contribute

This is our way of ensuring a purchaser is allowed to participate in a sale without having to add every address to a user registry. To prevent users from constructing the data payoad piece arbitrarily, our smart contract signs the hash of the tightly packed arguments with our “signator’s” private key. By doing this we are able to verify through our smart contract that the signature in the data payload passed with the transaction was constructed by Token Foundry.

There is a cool function within Solidity called ecrecover, which recovers the signer’s address from a message and a signature (if the signer actually signed the message). At the time of writing we are using the current implementation of open-zeppelins recover function which can be found here. https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/ECRecovery.sol

Conclusion

Sending a transaction on Ethereum can be a daunting task, but hopefully this post helped you understand a bit more about the behind-the-scenes of hitting ‘send’. We will be continuing to add more technical blog posts along with videos that will take you through sending a transaction from start to finish on the Token Foundry platform.

Stuart Hunter
Head of Technology

How Data Payloads Augment Smart Contracts was originally published in tokenfoundry on Medium, where people are continuing the conversation by highlighting and responding to this story.