Photo by Kevin Ku on Unsplash

Building a #DeFi application

Angel Java Lopez
3 min readMar 26, 2020

--

A few weeks ago I started working on an implementation of a DEFi proof of concept, for a talk I was preparing for the city of Montevideo (now suspended). It is based on lending and borrows. It is written in Solidity, and as usual, using TDD. They can read the code at the repository and commits by test. I also plan to deploy and test it into RSK testnet network.

If you do not know what decentralized finance is, you can consult my repository with resources, and a list of tutorials. I am not a finance specialist, but I wanted to describe the main ideas of what I am implementing as a software developer. My proof of concept implementation is based on Compound protocol ideas. For more info, read Compound finance simplified.

Tokens as Digital Assets

The basis idea is that users have ERC20 tokens. If you don’t know about this kind of tokens or what a token is, read Create Ethereum Token and Create ERC20 Token Tutorial.

A token smart contract keeps track of user balances

Also, a token holder could be another smart contract. Alternatively, we could use another point of view:

Alternative point of view: each user has tokens

But the real thing is: the token smart contract keeps track of the balances.

Token Markets

These tokens could be used in markets to lend and borrow them. In my implementation there is a market smart contract for each token, and there is an additional smart contract: the controller. This is similar to the Compound implementation.

Each token have a market. All markets in the system are known by the controller

Users can supply their own tokens to each market:

Each market has a dedicated token pool. The tokens in the pool are supplied by users.

And then, each market has a token pool: all the supplied tokens are managed as a pool, although the market smart contracts keeps each user balance, also.

Supply and Borrow

If a user has supplied tokens to the system (to any of the markets), he/she could borrow tokens, if his/her supplied token could cover the borrowed value. The controller, knowing all the markets in the system, enforce this rule: the borrowed value should be covered by enough collateral (other tokens) value:

Charlie could borrow token 3 from the market pool, having enough collateral value in other markets.

Topics to discuss in next posts: the borrow rate, the supply rate, the collateral rule implementation, and the liquidity of an account. Ie, a borrow could be paid by the borrower, but if the collateral value provided drops enough, it could be paid by anyone with tokens to restore the original borrowed ones, receiving the supplied collateral as a benefit.

Angel “Java” Lopez

--

--