Categories
Blockchain Finance Financial Services

How to tokenize assets: Real estate ICO

In the crypto space, tokenization is the buzzword of 2018. Here in Crypto Valley, one can run into an entrepreneur tokenizing a real asset nearly on a daily basis. What’s more, many of the projects are already at an advanced stage. Therefore, it’s not unreasonable to expect that by the end of Q4 many startups from Crypto Valley will be issuing tokenized assets such as gold & silver, art, real estate, and agricultural property. Tokenization of an asset, however, is a complex process, mainly because of the tokenomics it involves. Let’s focus on a real estate ICO.

Tokenization – real estate token

The complexity of token economics can be illustrated through the example of a stable real estate token. By ‘stable’ I mean there are no large price fluctuations on the value of the token. This is a common tokenization use case in the blockchain space at the moment, as real estate is generally an illiquid asset. By tokenizing it,  it’s possible to bring liquidity to the markets. So let’s try to build a real estate ICO!

For a real estate token, we would like the value to represent the actual value of the underlying asset. But how can we guarantee this? Just for the sake of example, let’s imagine that we have 100 million worth of real estate as the backing asset. We can also imagine that the ICO is capped at 100 million. Each token represents a proportion of the actual apartment, being a security token.  Let’s enter the time after the ICO has been successfully hard capped and the token listed on an exchange. We need to analyze two different things: when demand is higher than supply, and vice versa.

When demand surpasses supply

As the demand grows larger than the supply, we’ll see a price increase of the real estate token. This would be an ideal situation for a utility token or a security token of a more speculative nature. However, for our purposes that would not be ideal. The value of the token wouldn’t be backed by the real estate anymore and would start to grow. Just like in the many economic bubbles in the past.

The solution for stabilizing the price would be to allow an unlimited supply of tokens to be released to the market so that the real estate token issuers would be able to issue real estate to the markets per demand. Roughly speaking, this would mean that the token issuer would have to offer an unlimited supply of tokens to the markets.

Meeting the increasing demand brings a different problem to the table – how will the newly created tokens be backed. Will there be a pool of real estate larger than what was offered in the real estate ICO, or will the issued funds be held in escrow and used to purchase more real estate? Depending on the model chosen, and on legislation, it may be possible that issuing new tokens will require financial licensing.

When supply surpasses demand

Another problem arises when there’s a bigger supply of the token than there is demand. This would happen, for example, in a situation where a major token holder decides to liquidate their position all at once. Surely, one might argue that market forces wouldn’t lead to the price of the token going below the value of the underlying asset. However, this might not be the case – what if the market actors simply would decide to wait for a lower price and join the dumping party with the expectation to buy even lower?

We can solve this problem in a couple of ways. First, if we use an ERC-20 token, we can have the liquidity mechanism using Bancor. The tradeoff is that it will tie a large amount of the ICO capital to the Bancor smart contract. Another approach would be to directly build market makers into the exchanges that are used to trade with the tokens. However, as the number of exchanges grows, it could mean spreading the liquidity reserve in multiple locations simultaneously.

Exchanging the tokens

Another question comes to mind: where is the business model in all of this? The company could focus on growing the amount of real estate and deriving a cash flow from rental contracts. It could also consider other ways of getting income. For example, it would be possible to charge a transaction fee. Depending on the technicalities, this can be done directly on a smart contract. If a smart contract solution isn’t ideal, it can be directly implemented on a customized blockchain protocol.

This leads to the next question. Would it be ideal to use an ERC-20 token and integrate it into an existing exchange platform, or would it be better to use a customized blockchain protocol? An ERC-20 token is easy to integrate into different exchanges. However, it will have the limitations of Ethereum protocol.

Real estate ICO: What about regulatory compliance?

The final big question is how to deal with KYC/AML compliance. After all, if the token is to represent actual real estate, the investors may have legal rights to dividends and to the real estate itself. Therefore, we need to have a way to vet ICO investors. Also, the ability to invest and transfer the tokens needs to be limited to identified parties. The easiest way to solve the compliance aspects of security tokens is to whitelist the identified real estate ICO investors and use exchanges that only allow identified investors to trade. If you’re considering a dedicated blockchain, these control mechanisms need to be implemented at the protocol level.

I’d be happy to talk to you about tokenization, and your real estate ICO (or any other plans to tokenize something valuable!), if you’re planning one. Write to me using the form below!

Categories
Blockchain Financial Services

Blockchain legal issues with DAOs

In my first article, I covered the benefits and possible problems that come with joining a decentralized organization. Today I’ll focus on some blockchain legal issues concerning DAOs.

Keeping things safe

  1. At its core, DAO was designed as an informal group of parties which operates entirely within the algorithm of its code . Theoretically, they can stay anonymous. However, it’s impossible that this code would cover every possible future case. There’s the obligations and interaction mechanisms between different DAOs and between different members and participants of the DAO. Moreover, if there’s no formalized legal structure in place for this entity, courts will impose one. A DAO most resembles a general partnership in which members/partners jointly represent DAO and are liable for its actions and obligations. The DAO may not have assets from which to indemnify third parties. So, it lacks assets or legal form. Therefore, the court could see the entity as fiction and could allow a lawsuit to proceed against individual members .
  2. A safe approach for DAO members would be to create a standard legal entity to which the DAO belongs. Every change in the DAO membership will have to be reflected in the entity membership/shareholding structure.
  3. A DAO can control cryptoassets. They can represent almost anything, including real-world assets, fiat money, valuable objects like cars, houses or precious metals. Those assets should be put under control of multisignature wallets (escrow) which DAO members have control over. Of course, proportionally to their DAO membership shares.
  4. There are initiatives in development that plan to setup “virtual jurisdiction” within which DAOs could operate. They could then cooperate with each other safely and with clearly defined rules. What’s more, they could have dedicated arbitration procedures in case of an unresolvable dispute.
  5. A DAO smart contract could also include a clause referring to a private court which specializes in smart contract disputes. It’s far better to determine preferred jurisdiction beforehand, than let a plaintiff or a government choose it afterwards.

Blockchain legal issues – DAO

  1. In the real world a ‘principal’ is liable for its agent’s actions . Check out agency theory for more. An individual developer or software company that created a DAO can be considered as principal in some scenarios. That principal can be held liable for the actions of the DAO (and its members) without having any control over them.
  2. Legal language is very different from procedural computer language. Usually, a software developer isn’t able to express all legal details accurately. Development of specialized smart contract law programming languages is still in its very early stages.
  3. There’s no common way, yet, to represent fiat money on the blockchain. Here’s an attempt. However, most of the traditional contracts still need to represent value using fiat money or precious metals . Possibly, Central Banks can also digitize fiat money on the blockchain. Until that happens, most of the DAOs operations will be very limited in scope.
  4. If we treat a DAO as a for-profit company, there is whole set of unanswered questions. For example:
    1. Can DAO members or DAO itself claim expenses against profits?
    2. If the DAO needs to buy a physical asset, whose name goes on the paperwork?
    3. If the DAO creates and patents intellectual property, who’s the registered owner?
    4. How a DAO can own an internet domain when domains still need to be registered to a person or company?
    5. How should taxes be paid if the DAO (or its members) make a profit?

Final remarks

Naturally, my article doesn’t constitute any blockchain legal advice. But these are certainly blockchain legal issues to consider. A DAO is definitely an interesting initiative that can fix real problems. Just make sure you’re prepared for every contingency. If you’re not sure you are – consider our blockchain training sessions. We’ll work through your problems.

Categories
Blockchain Financial Services Technology

Blockchain immutability: Behind smart contracts

The Ethereum smart contract has taken the world by storm, with its wide adoption for ICOs. Smart contracts are, in essence, computer programs executed in a sandboxed environment, so one that restricts them. That restriction provides special functions and properties: the famous blockchain immutability is one of them. Let’s dive into those.

Blockchain immutability

As I wrote, one of the defining properties of smart contracts like the Ethereum smart contract is that their code is immutable . Blockchain immutability means that parties agree to the terms or “code” of the contract, that code can’t be changed by any party unilaterally.

The result of the execution of the smart contract is similarly unchangeable. Of course, that happens once the agreed-on code is executed and produces a result. The result should be objectively verified by the other party to that contract, or even by an external party. For example, this could be a regulator or observer. Only then you can be 100% certain it’s valid.

Free from external factors

The immutability of the results of the executed smart contracts stems from what I’ve mentioned at the beginning. What’s important is the context in which the smart contract is executed: sandboxes . That means the contract is free from the influence of any external factors. An environment like that guarantees the determinism of computational results.

T he only factors that influence the result are the input data to the smart contract, and the data stored within the smart contract environment . By the latter, I’m referring to the data that was stored there when smart contract was instantiated for the first time. Or, by the previous execution iterations of the same contract. In some smart contract environments (like Ethereum) smart contracts can also communicate with each other and influence the execution of one another. However, this is still done in controlled and deterministic way.

The Ethereum smart contract’s not the only one. Other implementations

Various implementations of smart contracts seek to leverage their benefits. Bitcoin’s smart contract language (script) is intentionally limited in complexity. The logic that can be expressed in it is very restricted. On the other hand, we have the Ethereum smart contract. The set of the operations that can be executed within the Ethereum Virtual Machine is much broader. Almost any reasonable algorithm or logic could be expressed in it, though there are still limitations on the number of operations per invocation.

Going even further, Hyperledger Fabric has no restriction on the complexity of the smart contract logic or the number of operations. That means it’s very powerful. However, it it also greatly increases the risk of node consensus divergence if that power isn’t used properly. Generally speaking, the level of expressiveness is a feature of a particular implementation. It can vary, providing different levels of security and strength for particular use cases.
It’s worth knowing the consensus doesn’t have to be immediate. Depending on the implementation, it might take around 1 hour (Bitcoin) to reach the semi-final consensus, or be almost immediate (Hyperledger Fabric). That’s despite the fact that once the consensus is reached, the smart contract execution result is provable and immutable.

Controlled access

Some smart contracts need to have access to structured data from the outside of their environment . In most implementations, controlled access to that data can be provided by privileged actors. They’re able to fetch the data needed at the specified time. Then, they can provably transform the data to a format that can be processed by the smart contract. Actors like that are called Oracles. They’re an inherent part of the productive smart contract ecosystem. They don’t change the other properties of the smart contracts. Oracles also work in the same sandboxed environment as the other smart contracts. Once the data is provided, it can’t be modified and is ‘provable’ forever.

Can smart contracts function without a blockchain?

If we want to execute smart contracts with the listed properties, they need to have access to some form of history inalterability. At the least, we’d need a way to prove that the history was changed and the observed results can’t be trusted any longer.

Blockchain is one technique that gives that particular feature but there’s research being done on other techniques. One of them is DAG (directed acyclic graph) where the smart contract transactions form a graph of relations (not being part of the chain of blocks). Yet another approach was undertaken by the Corda platform. There are no blocks in Corda, and transactions are exchanged directly between interested parties in the form of cryptographically signed sets of data.

Blockchain immutability brings many advantages to various industries, and is one of the features that inspire our clients to get on the blockchain. So, the Ethereum smart contract and the blockchain platform are what we deal with every day at Espeo Blockchain. That, and much more. If you’d like to leverage blockchain immutability in your project, we’re interested! Let us know in the box below.

Categories
Blockchain Finance Financial Services Software

Ethereum gas: how to pay it on behalf of your users

On Ethereum, every transaction that changes the state of a smart contract costs a small fee: this is called gas. Most commonly, end users pay gas while interacting with a smart contract. However, when you’re making a profit on your product by charging some transaction fee or just want to gain many users quickly, you may think about covering the Ethereum gas costs yourself. Well, good news — it’s achievable! In this article, I’ll describe how to do this from both the business side and technical side.

To calculate the precice amount of gas you need to know two factors: Ethereum gas price and the complexity of the operation you want to execute. The current average gas price of Ethereum depends on the current demand on the Ethereum network. Now, let’s see how you can offload the gas costs from the transaction creator to the platform itself.

Blockchain use case: P2P options exchange

The need for offloading the transaction fee in order to achieve cheaper prices is real! We’ve recently faced the problem of moving as much Ethereum gas cost as we can from the end user to the contract creator. The project in question was a blockchain peer-to-peer options exchange, which got a percentage of profit from every successful option settlement. The goal was to encourage people to use the product by waiving any additional cost, just like in non-blockchain solutions.

One of the functions that needed to be free for the users was a standard ERC20 functionality – approve(). User A can allow user B to transfer a certain amount of tokens from user A’s wallet. This method, like any other, normally costs Ethereum gas to execute, but we want to achieve this with no cost to the user. Let’s call the target solution zero-fee allowance. The following requirements must be met for a trusted and secure solution:

  1. The transaction has to be executed by the contract owner, not the end user.
  2. It has to be clear which action is performed by the contract owner on behalf of which end user.
  3. The transaction can be invoked only once.
  4. Two transactions containing two intents by the same end user have to be executed in the order of creation.

Dealing with the Ethereum gas cost challenge

We began by searching through Ethereum Improvement Proposals for problems similar to ours and maybe some solutions. Jackpot! Issue 662 addressed our problem.
After a detailed analysis we were ready to develop our own solution based on what we learned.
We divided the process into 3 parts:

  1. Arbitrary data (the intent) is signed offline using the end user’s private key. The data contains the approve method signature, all parameters and contract address on which the request should be executed. The resulting data signature is sent along with rest of data to the server. Within this step, the user doesn’t make any state changing transactions, so there’s no transaction fee.
  2. The server gets the data from the end user and pushes it to the network using the smart contract owner’s key. The smart contract owner pays the transaction fee.
  3. The contract verifies if the sent data is really the end user’s intent by validating the signature. Then it checks for replay attacks and user intent’s execution order. Lastly, it executes the actual approve function.

Implementation

This part describes the technical solution. So, if you’re not interested in the guts of implementation details, then just skip to the next section, where I’ll discuss the financial aspect of the zero-fee allowance approach.

We based our solution on StandardToken from OpenZeppelin framework. It gave us base methods like the aforementioned approve(). Next, we moved to validating the end user’s intent in the getSigner() function. Firstly, the end user address is recovered from the data signature. Then, the signature is checked against the signature calculated for the arbitrary data passed by the end user. In this step, the intents order is checked by incrementing the nonce value. Lastly, the intent is checked for any previous executions.
After all these checks pass, the flow continues like the standard approve method with the spender address being replaced with the one belonging to the user who signed the message. For readability, the code is split into three methods – checkProvableApprove and provable_approve. The first one is constant and can be used for checking intent correctness, while the second changes the state.

Business calculation of the Ethereum ETH price

Let’s take a look on price per unit that user has to spend per transaction with zero-fee allowance in comparison with the traditional approach.

The gas price and ETH/USD ratio given at the time of writing:

Gas price (Gwei) ETH/USD
49 995.5
Method Gas used Wei cost Ether cost USD cost
Zero-fee allowance 98213 4.81244E+15 0.004812437 $4.79
Traditional allowance 45324 2.22088E+15 0.002220876 $2.21

The conclusion is quite clear. The zero-fee allowance approach costs over 2 times more than when the approve() function is executed directly by the user. In our use-case, that move was worth it, but it should be an individual decision. After all, as the popular song goes, “it’s all about the money”.

If you liked this article, then give it a share. We’ve got more great stuff on our blog (e.g. a guide on how to start an ICO), so make sure you subscribe to our newsletter to be up to date!