Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feature: on-chain loans (GalaChain#458)
Adapted from the original September 06, 2022 commit message. Implement the initial chaincode and data structures for loans/leasing. Some details on requirements for leasing/loaning on chain were documented in ancient times, internal link redacted. At the time of this writing, (Sept 6th 2022) this document posited two types of potential leasing, described as the "short term solution" (or "centralized authority") and "long-term" (or "web3" solution). The centralized authority solution essentially relies on a trusted authority (such as a game server identity) to manage or facilitate the lending from owner to borrower. For some applications, prompting for and receiving a signature from the user's private key may presents unique UI challenges that might be difficult to solve in game or in-store. Thus the "centralized solution" is available for applications or user collectives that prefer the approach of a trusted mediator/curator. The web3 solution permits users to lend directly, peer-to-peer. No third party required. This merge introduces on-chain support for both models above in an abstract way. Aspects of loans that make sense to provide directly in the SDK are included, with the expectation that most applications will have their own additional chain calls and handling for their specific use cases. This technical designs introduces semantics borrowed from the fields of archiving, collections curation, and cultural institutions management (museums, libraries, archives, etc.). For example, we use the term "Loan" in code rather than "Leasing", and "registrar" rather than "broker". If we believe that NFTs are digital cultural property similar to artwork or artifacts, and we do, then using terminology from the fields of art, manuscript, and antiquities curation is more apt than that of the financial services industry. "Registrars focus on... acquisitions, loans, exhibitions, deaccessions, storage, "packing and shipping, security of objects in transit, insurance policies, and risk management." https://en.wikipedia.org/wiki/Registrar_(cultural_property) Retrieved 2022-09-06 User stories written to shape this feature: As an NFT owner, I want to loan out my item(s) and (potentially) receive rewards while not in use, so that my cultural property can be experienced more broadly while being accessible and interoperable to a larger audience and user base. As a NFT borrower, I want to access and use more valuable or powerful items than I can afford, at lower cost within a specific time-boxed period, so that I can enjoy a richer experience of cultural property than I might otherwise be able. As an NFT owner, I don't want the borrower to transfer my NFT without my authorization, so that I maintain my ownership. In other words, the NFT is locked to the loan and non-transferable for the duration. Loans only applies to NFTs in this implementation, however this code is expected to serve as a significant start for fungible token loans. The "loan" semantic certainly can apply to fungible tokens as well. There is a 1:1 relationship between a `LoanOffer` entry on-chain and an NFT `TokenInstance`. But `OfferLoan()` can take a partial key and create multiple `LoanOffer` entries, similar to how partial key allowances work. The token should be locked to the loan for the duration specified. This implementation is intended to be generic and provide the basic primitives for offering loans, accepting loan offers, locking tokens to a loan, and preventing ownership transfer while the loan is in effect. The implementation does not currently account for application-specific aspects of loans, including whether a loan requires a payment to enter into, incurs rewards to the owner, etc. These details are left for future enhancement or implementation by consuming clients/developers. The provided types and methods could conceivably be used alongside chaincode specific contracts or extended to support further application or domain specific use cases. The current data structures and chaincode methods can record information to the ledger such as: * this token was loaned by whom, to whom, from whom, etc. * when loan was filled * when loan ended * the status of the loan completion (e.g. fulfilled, canceled) * token locked / unlocked Individual applications are expected to pick up further implementation details in their respective channels. This initial implementation is considered experimental and is subject to change if early adopters choose to utilize it and request or submit changes.
- Loading branch information