Almost 5 months ago we launched our first alpha version of the NanoLoanEngine; this engine is the core of the RCN protocol, it handles all the loans and their logic. Back at that time we also launched our first draft of how an Oracle and a Cosigner should work.
This engine has been tested in our production environment, Ripio started to request loans on the Engine, created an Oracle and created the rcn.exchange platform to simplify the lending process.
What did we find?
The Oracle V1 contained the current rate stored on the state of the contract, the owner of the Oracle must continuously send transactions updating the rate.
This had its advantages, mainly because any other contract could consume the oracle without doing any external call or waiting for a response; but it also had its flaws, it’s expensive to update it often (and cryptos kind of fluctuate), and if the network becomes saturated with an ICO, rally or feline, the rate stays outdated, rendering the oracle unusable.
The cosigner also had a number of inefficiencies on the first version, it was set by the creator of the loan but paid by the lender. If a lender decided that he didn’t want the insurance provided, they didn’t have the option to remove it from the loan or change it for another one.
It also has another problem: every designated cosigner must call the “approve” function. Though this generates a small cost to the cosigner, this limits the number of options that a cosigner can provide, and it’s bad for the competition among them.
What is new in the V2?
We reshaped the NanoLoanEngine; the fundamental principle is the same, but we put our new experience and build an improved version.
Name!
We added a name to our versioning; this allows us to reference it quickly, also it plays an essential role with the ERC-721 non-fungible token standard.
The name for the V2 is Basalt… Why? Because it’s a rock, and we come from Ripio, which means gravel in Spanish, get it? Ok, nevermind, let’s move on.
Oracle V2
The Basalt Oracle is now virtually free to run, the owner and maintainer don’t have to update the Oracle with the new rate regularly. When the getRate method is called it receives a data parameter; this data should be used by the Oracle contract to build a rate and return it to the caller.
For example, a signed message could be used to validate the authenticity of a rate and deliver that to the caller; as seen in our reference implementation:
This is an overall more flexible model; it still allows the V1 flow, but now more complex interactions can be built using the Oracle interface.
Cosigner V2
When a loan is requested on Basalt, the creator does not have to define a cosigner, when the lender calls the “lend” method, it also passes which cosigner wants to use and the data with the cosigner conditions, this allows the lender to decide between a set of cosigners and different insurance offers.
The cosigner accepts the conditions using a callback when the lending starts, the requestCosign method on the cosigner contract is called passing the engine, loanId, and data, the target cosigner should validate all that parameters, and if it wants to become the cosigner for that loan, it should create a liability on his contract and then call the method “cosign” on the engine, if that does not happen the lend transaction fails.
function cosign(uint index, uint256 cost) external returns (bool) {
Loan storage loan = loans[index];
require(loan.status == Status.lent &&
(loan.dueTime - loan.duesIn) == block.timestamp);
require(loan.cosigner != address(0));
require(loan.cosigner == address(uint256(msg.sender) + 2));
loan.cosigner = msg.sender;
require(rcn.transferFrom(loan.lender, msg.sender, cost));
return true;
}This flow gives the cosigner the flexibility to make multiple “insurances offers” without extra cost, to the lender the freedom to choose between various cosigners or none at all, and it’s also robust. The callback guarantees that there is an agreement between the terms of the loan, the lender and the cosigner.
ERC-721
The new ERC721 it’s the new standard for non-fungible tokens, implemented by Decentraland and Cryptokitties. We are making the interface to manage the ownership of the loans (as a lender) a non-fungible token.
This allows quick integration of the RCN loans in exchanges, wallets, explorers, etc. For example, you can watch in etherescan the creation, transfers and the payment of the loan.
Audit
We are thrilled with the public audit that Coinfabrik performed of our Basalt engine, the result can be seen on their blog:
Next steps
We already deployed our engine both in the Ropsten testnet and the Ethereum mainnet, we also have a working alpha dapp working with our Ropsten testnet instance.
We are also working in our aproach to identity and scoring, we are starting an open discussion in Github, you can take a look and participate here:
In the next weeks, Ripio is going to launch an Oracle V2 and start requesting loans in the Basalt engine; more companies are on the way to start participating on the network as Score providers, Wallets, Oracles, and Borrowers.
