I always thought that tokenization is one of the most interesting concepts in blockchain. Basically, tokenizing means issuing a token that are linked to a real-world asset. The link can probably be implemented in multiple ways but if I understand the legal context properly, the primary way is a regulatory framework. I will definitely be doing more research into this, but first I wanted to create something of substance that I could use as a point of departure. I went with my first idea which is short-time rentals.

‍

In 2017 the news about a successful hacker attack on the Parity wallet emerged. The Parity wallet was a Smart Contract wallet that could be used for managing cryptocurrency funds. The attacker took over the control of the Smart Contract and transferred all of the currency deposited in it to his account. The damage has been estimated at USD 30M and the hack prompted waves of negative responses from the public.

‍

‍

Why was this possible?

The developers of the Smart Contract code were using a proxy that was delegating calls to the current main implementation. This kind of proxy functionality is a common way of implementing upgradeability for contracts. Any call to the proxy contract itself that does not match existing function's signatures is being forwarded for execution within the proxy context via the Solidity's delegatecall instruction.

‍

This entry is part of a series of blog entries in which I attempt to build a comprehensive threat model for the blockchain ecosystem. Check out the introductory entry.

When it comes to services on blockchain, we can view them similarly to regular services in terms of functions  and threats. Service providers, as in off-chain applications, are trying to make a coin by providing useful products and services to their users. So we're looking for example at:

- Fungible and non-fungible token contracts
- Token exchanges
- On-chain wallets
- Lending smart contracts
- DAOs
- many other types of service.

I will also refer to services as smart contracts.

In case of service developers, besides looking at the threats related to the service alone, it's also worthwhile to look at the development process (Software Development Life Cycle). I will do this in a separate blog entry because I think that due to numerous differences it makes sense to separate these two aspects.

Although risk analysis related to the exposure of assets that remain under control of service provider is a more general task than threat modelling, I feel that I should mention as a part of this entry's introduction that in case of on-chain applications risks can be considerably higher than in case of off-chain equivalents. The reasons for this include:
- sensitivity of assets under control
- volume of assets and transactions
- exposure in terms of code and data visibility
- unknowns that are related to the use of emerging technologies

For this reason I think that potential service providers should exhibit due diligence and due care for safeguarding assets under their control and understanding threat model of their perspective is a key aspect of this.

All right, let's explore the threats. As usual, I will rely on the STRIDE methodology.

‍

‍

‍