Asset Tokenization Protocol: High Level Tech design (Updated)

This article is meant for the internal team at Konkrete, as well as any other teams that may intend to build on the open source Asset Tokenization protocol.

This article builds on and updates the ideas laid down in

Asset Tokenization Protocol: High level architecture

While the fundamental principles and much of the architecture described above is not changing, we are refining, adding some elements to it as well as making things clearer as our own understanding of how real world assets can be tokenized improves.

Tokenizable assets have the following attributes

1. Party A
2. Party B
3. Value provided by A to B
4. Value provided by B to A in return
5. Date by which the terms need to be fulfilled
6. Documentation of any real world agreements and security taken

Consider an invoice, in which the above parameters are

1. Seller
2. Buyer
3. Services or goods sold
4. Money due
5. Date money is due by
6. Copy of the invoice and any real world security agreements between the above parties

We also add one more parameter called status

The process of tokenization would be:

Seller initiates the invoice and sends it to the buyer. This is done via the invoice token contract deployment via Metamask (or other non custodial cold wallet).

At this point the status will be 0: Contract initiated

The buyer confirms that he is due as per the terms of the invoice (Signed via wallet).

Once both parties sign off the status will be 1: Confirmed.

At this point the tokens for the contract can be generated and they go to the sellers wallet.

In theory the seller can now sell these tokens to any willing buyers. These tokens represent a claim on the buyer for the agreed upon payment at a future date.

However in the event that the buyer does not pay, there is a need for off-chain enforcement. This cannot be done programmatically as part of the smart contract.

It is also plausible that there is a role for an “onramper” who facilitates the tokenization of the off-chain contracts such as real estate mortgages etc.

Such an entity would take the necessary real world security and be responsible for enforcing it. They could even underwrite by forwarding the necessary funds.

It becomes necessary to update our token contract to make provisions for an “onramper” who collateralizes his on-chain assets in the contract and wears the risk of the buyer/borrower not coming through.

When a contract is confirmed, anyone may lock up necessary amount of ETH as collateral in the smart contract.

They can add their wallet address to their contract and would get a fee into this wallet when the buyer repays for providing the fail-safe on-chain collateral.

If the buyer does not repay then they lose the collateral (ETH) they had locked up in the smart contract. The onrampers may pursue off-chain action against the buyers/borrowers of their own accord.

Those who own the contract tokens may redeem them against the locked up collateral.

If the buyer pays as expected then the collateral unlocks and reverts back to the onramper with some fees.

The contract token holders can redeem their tokens against the payments made by the buyer at this point.

When the contract is secured with collateral, the status changes to 2: collateralized.

When the buyer pays, the status changes to 3: completed.

If the due date is past and the status is only 2: collateralized and not 3: completed, then the token holders have a claim against the collateral that is locked.

Note that once the collateral is locked, it is not absolutely necessary to seek a financier to buy the contract tokens.

Once a contract is collateralized, it can automatically plug into a money market like Compound, AAVE or Torque and get the necessary coins such as DAI by using the collateral that is locked in.

The money borrowed would go through to the seller and when the buyer repays, the contract would automatically repay that on the money market and unlock the collateral put in by the onrampers.

The system can start by using ETH as collateral. In the mid to long run we want to use our own tokens as acceptable collateral. This would operate similar to SNX tokens used by Synthetix to mint assets.

Our tokens, lets call them ATP (Asset tokenization protocol) tokens, can be locked up by those who own them and earn fees when the contract pays. The entity behind it would be responsible for enforcement if it comes to that stage.

Another model could be the staking of ATP happens automatically and the fees flow to a common pool, which is used to buy back ATP. If the system is in need of more funds, more ATP can be minted dynamically akin to MKR.

The objective would be to make ATP widely accepted enough so that it can be plugged into existing money markets, or enjoys its own liquidity on Uniswap.

The parameters/interfaces of the contract now are

1. Party A
2. Party B
3. Value provided by A to B
4. Value provided by B to A in return
5. Date by which the terms need to be fulfilled
6. Documentation of any real world agreements and security taken
7. Collateral locked up
8. Address where fees flow to
9. Status

Anyone spinning up an instance of this protocol may have their own admin module where they create a list of acceptable tokens for collateral.

There may also be a need for a price oracle which tracks the price of the locked collateral and initiates liquidation if the price of the collateral falls below a certain threshold.

Go to market strategy

For small P2P assets such as invoices which are not publicly verifiable, it would be necessary to use ETH as collateral. This ETH can then be plugged into a money market as described above.

For larger assets such as first mortgage which can run into millions of dollars per transaction, having such a large amount of ETH locked as collateral would be wasteful as well as potentially nonviable.

However first mortgages can be publicly verified.

A public unlisted company or a Registered MIS in Australia can maintain its own registry which can be in the form of ERC20.

Such a special purpose entity can take the mortgage and put up its shares/units as collateral in the form of ERC20.

Given that the mortgage and company incorporation can be publicly verified, that should encourage trust in the system.

The initial roll out would have to be done for smaller assets and using ETH as on-chain collateral to gain market acceptance.

The difference between the contract amount and the asking amount will be split 3 ways

1. Bulk of it will go to the financier
2. A small portion will go to the collateral provider
3. A small fee will go into a pool which will be used to provide liquidity to any ATP holders

The intention of the fee to ATP holders is to create value for backers of the venture. Any one with ATP token has a claim to a portion of the fee pool. They can encash their ATP tokens from the pool. The encashed ATP tokens would then get burnt.

ATP token holders will also participate in governance of the protocol and vote on various upgrades to the system. More ATP may be minted similar to MKR if the system is in stress and needs additional capital injection for some reason.

Eventually the objective is to make it possible to use ATP as collateral instead of ETH.

In the very short run however there are a few other solutions beyond ETH that can be used as collateral. While ETH is extremely liquid, it is also quite volatile which means that in order to use it as collateral we would also need oracles and active liquidation processes to monitor the collateralization levels.

The use of a stable coin such as DAI as collateral does not make any sense as in such a case why not simply front the DAI to the seller and eliminate the collateralization step completely.

A better solution would be to allow the use of ctokens from Compound, itokens from bzx, atokens from AAVE money markets and Chai from DSR to be used as collateral. These represent composable ownership claims on loans made and are generally liquid, which means they can be converted to DAI on demand.

Given that they represent overcollateralized debt, they are fairly safe and would not need conservative collateralization.

cDAI worth $100 as of today can easily serve as collateral of $100 for a loan contract.

This also allows us to co-operate with existing money markets and build distribution by providing an outlet for their lenders to amplify their earnings on their ctokens, itokens etc.

Collateral providers can lock their c, i, a, chai tokens for the duration of the contract and earn extra fees on that apart from the interest they are already making on the money market.

In the event of a default, the collateral tokens would be redeemed on the respective portal to get the required DAI and pay the financier. Any excess would be paid back to the collateral providers.