SxT LinkLend

Inspiration

Credit should be available to those who need it, from those willing to provide it. An open marketplace where lenders and borrowers may negotiate fair terms for loans should be a goal of any decentralized financial system. Rather than a centralized system of credit scores, dominated by banks and fed by a limitless reservoir of money created on demand, I envision instead a system used and served by individuals all over the world, with lenders making their evaluations of anonymous borrowers based on their measurable DeFi history.

DeFi's lending services typically require on-chain overcollateralization to work, but what if a different form of off-chain collateral could be used to secure on-chain loans?

I propose "identity collateral", where borrowers may prove their identities to Licensers, who keep their private information secret. Only in the event of default will the anonymous borrower's identity be revealed, for the purpose of legal remedy and debt collection on behalf of the Lender, where the output of a Chainlink DON carries legal weight in proving the debt obligation of an on-chain borrower.

What it does

LinkLend relies on both Space and Time (SxT) and Chainlink Functions to handle the secret information of Borrowers and Lenders. A DAO selects and approves various Licensers capable of verifying the identities of Borrowers; Licensers record Borrowers' confidential information via a Functions call to SxT.

Borrowers may then offer loan proposals requesting certain amounts of tokens. Lenders, who may join the platform permissionlessly, may offer terms to any open proposals. If a Borrower accepts the terms, they must pay off the debt before expiry, or they will enter default. Chainlink Automation will trigger a Functions call, retrieving the secret identity information of a defaulted Borrower and sending it to a secret email address provided by the Lender. The Lender may then proceed to Collections, another service whitelisted by the DAO.

How it was built

The system's design presupposes the existence of a SxT BISCUITS schema accessible solely by a Chainlink DON. As the name suggests, the purpose of this schema is to store biscuits for registered projects.

A contract may register a table on the BISCUITS schema when obtaining its Functions subcriptionId. In doing so, the DON will also create a schema on behalf of the contract, on which the contract may create and update tables through Functions calls.

Using this project as an example: When the LinkLend contract requests a subscriptionId, it also registers for SxT services by submitting its project name as "LINKLEND". The Chainlink DON will automatically create a LINKLEND table under the BISCUITS schema, and it will also create a LINKLEND schema for use by the contract.

When the DAO approves a new Licenser, they configure certain on-chain variables and send a Functions call with the Licenser's name. The Chainlink DON first creates a biscuit for the new table, and stores it on the BISCUITS.LINKLEND table. It then creates the table under the LINKLEND schema, LINKLEND.(licenser).

When the Licenser begins adding Borrowers, it does so through a Functions call that passes the Borrower's information as a secret. The DON retrieves the biscuit for LINKLEND.(licenser) from BISCUITS.LINKLEND, and then uses it to add the Borrower's info to LINKLEND.(licenser).

Challenges

Some of the features necessary for this project to work do not yet exist. DONs do not have their own SxT Authorization tokens, do not have a BISCUIT Schema, cannot generate biscuits, and cannot provide a signature hash in an email. For this system to be possible, the DON would need exclusive, secure possession of the credentials needed to access user secrets, and a means to prove that its off-chain messages are legitimate.

Accomplishments

Nevertheless, should such features one day become available, I believe that permissionless credit systems and many other new decentralized financial applications relying on confidential information could become possible. I enjoyed designing this particular system and was proud to both imagine how it might work and to build a prototype using this early technology.

Lessons learned

How to use Space and Time and HTTP Requests in Chainlink Functions!

What's next for SxT LinkLend

From a usability standpoint, the system needs more sophisticated means of tracking interest, and encouraging regular payments rather than presenting a single terminal deadline. A hypothetical DAO may also consider imposing rules for the amount of interest Lenders may offer in their terms.

Beyond showing off their DeFi history, Borrowers may also wish to demonstrate creditworthiness by proving they possess off-chain collateral, without necessarily needing to reveal what that collateral is. It would be desirable to establish a formal process of transfer in the event of default.

There are several technical and legal problems that need to be solved first before a system like this could exist, DON-controlled tables and biscuits notwithstanding.

Not explored is the problem of decentralized debt collections. The collections process will vary by locality and to be truly operational would require integration with the legal system. Like Licensers, Collections services would be permissioned by the DAO and would most likely be public organizations with a history in debt collection.

The system's point of failure is the Licenser. A malicious or incompetent Licenser could upload the wrong on-chain address for a given identity, which could cause someone to be falsely blamed when that address defaults on a loan. A malicious defaulted Borrower could also attempt to sue the Licenser, claiming that their defaulted address in fact belongs to someone else.

Therefore a Licenser will need a method of linking an identity to an on-chain address that is trustless, confidential, and verifiable in the event of default. This is especially true to prevent identity theft, where a person entirely uninvolved with the platform could be blamed for a default.

The Licenser’s only job is to ascertain that a borrower is human, not to determine their creditworthiness; this is nonetheless a form of permissioning requiring the applicant meet certain restrictions to access the platform. The identification process preferably will be trustless, dependent on a reliable form of human decentralized identity.

Impersonation due to stolen private keys is another inherent risk. Countermeasures like DECO and multiple methods of verification could help defeat this and other potential problems relating to user identity.