-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERC 1850 - Hashed Time-Locked Principal Contract Standard #1850
Conversation
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
eip: 1850
title: Hashed Time-Locked Principal Contract transactions
author: Matthew Black [email protected], Tony Cai [email protected], Atomic Loans team [email protected]
status: Draft
discussions-to: #1851
type: Standards Track
category: ERC
created: 2019-03-19
Simple Summary
This EIP describes a script for a generalized debt agreement contract based on Hashed Time-Lock Contract (ERC 1630) transactions according to the Atomic Loans specification (https://arxiv.org/pdf/1901.05117.pdf).
Abstract
A Hashed Time-Locked Principal Contract (HTLPC) is a script that permits a designated party (the "lender") to provide ERC20 denominated funds for a debt agreement for a specified amount of time, with collateral locked on another blockchain (denoted as the collateral blockchain for the purposes of this EIP). It also permits a second party (the "borrower") to withdraw the lent funds once their request to borrow has been approved by the lender, repay the loan after the loan period has passed and in the case of default, liquidate the collateral.
Motivation
HTLPC transactions are a safe method for exchanging multiple secrets for the purposes of executing a cross-chain debt agreement, due to the ability to recover a percentage of funds from an uncooperative counterparty.
HLTPC's enable cross-chain atomic loans
Definitions
msg.sender
: is always the address where the current function call came fromborrower
: entity that locks collateral on another blockchain and receives loan amount fromlender
following the approval of theborrower’s
borrow requestlender
: entity that contributes funds to the HTLPC, to be borrowed by theborrower
upon the locking of collateral on the collateral chain and thelender’s
approvalbidder
: entity that bids on the collateral to enable liquidation of the collateralrepay
: when theborrower
pays back theprincipal
+interest
beforeloanExpiration
default
: when theborrower
fails to pay back theprincipal
+interest
before theloanExpiration
secret
: random number chosen by theborrower
orlender
, revealed to allow the parties to change the state of the debt agreementsecretHash
: hash of thesecret
, used in the construction of HTLPCnow
: current block timestampprincipal
: the amount borrowed within the loan, upon which interest is calculatedinterest
: a percentage amount of the loan principal paid by theborrower
to thelender
, in addition to the repayment of principalapproved
:bool
state where if true, the request to borrow, as well as the collateral from theborrower
has been accepted by thelender
bidding
:bool
state where if true, third partybidders
are able to bid on the collateral in order to liquidate itcurrentBid
: highest bid on the collateral so farliquidatedCollateralWidthdrawn
:bool
state where theborrower
andlender
have withdrawn their share of the liquidated collateralSecretA1
: secret generated by theborrower
, used to prove that theborrower
has withdrawn the loanSecretA2
: secret generated by theborrower
, used to allow thebidder
to withdraw the liquidated collateral fundsSecretB1
: secret generated by thelender
, used to accept the locking of collateral byborrower
, enablingborrower
to withdraw the loan amountSecretB2
: secret generated by thelender
, used to refund themselves in the event they aren't satisfied withborrower’s
locking of collateral. Also used to acceptborrower’s
repayment of principal plus interestSecretB3
: secret generated by thelender
, used to allow thebidder
to withdraw the liquidated collateral fundsSecretC
: secret generated by thebidder
, used to accept the signatures of theborrower
andlender
for authorizing the liquidation of collateralApproveExpiration
: timestamp after which thelender
can no longerapprove
the loan by accepting requests to borrow from theborrower
LoanExpiration
: timestamp before which theborrower
must repay the loan; or otherwise risk the liquidation or seizure of their collateralAcceptExpiration
: timestamp before which thelender
must accept the repayment of the loanBiddingExpiration
: timestamp that determines the amount of time allocated to bidding before seizure period occursApprove Period:
During this time, the
lender
deploys the HTLPC. Following this, the borrower locks their collateral on the collateral blockchain in a Hashed Time-Locked Collateral Contract (HTLCC) (Bitcoin version specified here: https://github.com/bitcoin/bips/blob/master/bip-0197.mediawiki). Thelender
then either revealssecretB1
to signify that they are satisfied with the collateral, and the borrower can withdraw the loan by revealingsecretA1
. If thelender
is not satisfied with the collateral locked by theborrower
, thelender
can refunds their loan amount by revealingsecretB2
, which will subsequently allow the borrower to refund the collateral amount they deposited.Loan Period:
Once the
borrower
has withdrawn the loan amount, the Loan Period begins. Once the Loan Period is finished, theborrower
is expected to repay the loan. If they do, thelender
can then accept the repayment by revealingsecretB2
, enabling the borrower to refund their collateral amount. In the case that theborrower
defaults or does not repay the full principal plus interest amount, thelender
can choose to not accept the loan repayment, and the parties can opt for liquidation of the collateral in the Bidding Period.Bidding Period:
In the case of a default or the
lender
not accepting theborrower
repayment, thelender
andborrower
can opt for liquidation of the collateral through the process of third party bidders bidding on the collateral. The Bidding Period can be initiated by either thelender
or theborrower
. Once the bidding timeout occurs, thelender
andborrower
must each provide a signature, followed bysecretC
revealed by the winningbidder
once they have checked that the signature is proper. Finally, thelender
andborrower
must each revealsecretA2
andsecretB3
to allow the collateral to be withdrawn by the winningbidder
.Seizure Period:
In the case that either the
lender
orborrower
don’t accept the bid, thelender
can seize a percentage of the collateral. The amount is dependent on the amount of collateral locked in the Seizable Collateral script and Refundable Collateral script as described in the BIP (https://github.com/bitcoin/bips/blob/master/bip-0197.mediawiki). During this period theborrower
can also refund the funds locked in the Refundable Collateral script.Refund Period:
In the case of a default where the
lender
does not seize the collateral locked in the Seizable Collateral script, then the borrower can refund the funds locked in the Seizable Collateral script described in the BIP (https://github.com/bitcoin/bips/blob/master/bip-0197.mediawiki).Specification
Constructor
The
msg.sender
transfers funds to the smart contract during its deployment.Methods
fund
The
msg.sender
orlender
transfers tokens for the loan amount to the contractSHOULD throw if
funded
is trueapprove
The
msg.sender
orlender
approves the locking of collateral done by the Borrower on the collateral blockchain.SHOULD throw if
msg.sender
does not equallender
addressSHOULD throw if hash of
_secretB1
does not equalsecretHashB1
SHOULD throw if
now
is greater thanapproveExpiration
Note
secret
can be any bytesize, but that should be specified by the two parties before the HTLC is initiated. The recommended size is 32 bytes.withdraw
The
msg.sender
orborrower
withdraws the loan amountSHOULD throw if hash of
_secretA1
does not equalsecretHashA1
SHOULD throw if hash of
_secretB1
does not equalsecretHashB1
SHOULD throw if
approved
does not equal trueacceptOrCancel
The
msg.sender
orlender
accepts theborrower
repayment of theprincipal
plusinterest
SHOULD throw if hash of
_secretB2
does not equalsecretHashB2
SHOULD throw if
now
is less than or equal towithdrawExpiration
SHOULD throw if
now
is greater thanacceptExpiration
SHOULD throw if
bidding
is truepayback
The
msg.sender
orborrower
repays the loan amountSHOULD throw if
msg.value
does not equalprincipal
plusinterest
Note that in this version, it is expected that the borrower make just one repayment, which covers the entirety of
principal
plusinterest
refundPayback
The
msg.sender
orborrower
refunds the repayment amount they put forth in the event their repayment is not accepted by thelender
SHOULD throw if
now
less than or equal toacceptExpiration
SHOULD throw if
repaid
is falseSHOULD throw if
msg.sender
is not the borrowerstartBidding
The
msg.sender
(either thelender
orborrower
) initiates the bidding processSHOULD throw if
repaid
is trueSHOULD throw if
withdrawn
is falseSHOULD throw if
now
is less than or equal toloanExpiration
SHOULD throw if
msg.sender
is neither aborrower
address nor alender
addressbid
The
msg.sender
(anyone who is interested in bidding on the collateral) bids on the collateralSHOULD throw if
bidding
is nottrue
SHOULD throw if
now
is less than or equal toloanExpiration
SHOULD throw if
now
is greater than biddingTimeoutExpirationSHOULD throw if
_bidValue
is less than or equal tocurrentBid
SHOULD throw if token balance of
msg.sender
is less than_bidValue
provideSignature
The
msg.sender
provides asignature
for the collateral blockchain enabling thebidder
to spend thecollateral
in the liquidation processSHOULD throw if
now
is less than or equal toloanExpiration
provideSecret
The
msg.sender
provides asecret
to enable thebidder
to spend thecollateral
in the liquidation processSHOULD throw if
now
is less than or equal toloanExpiration
if
msg.sender
is theborrower
, then SHOULD throw if the hash of_secret
does not equalsecretHashA2
if
msg.sender
is thelender
, then SHOULD throw if the hash of_secret
does not equalsecretHashB3
if
msg.sender
is neither thelender
orborrower
, it SHOULD throwwithdrawLiquidatedCollateral
The
msg.sender
(eitherborrower
orlender
) withdraws the liquidated collateralSHOULD throw if
now
is less than or equal tobiddingTimeoutExpiration
if
msg.sender
is the borrower, then SHOULD throw ifborrowerLiquidatedCollateralWithdrawn
is trueif
msg.sender
is the lender, then SHOULD throw iflenderLiquidatedCollateralWithdraw
is trueif
msg.sender
is neither the lender or borrower, it SHOULD throwrefundBid
The
msg.sender
orbidder
refunds their bid in the case that theborrower
andlender
do not opt into liquidating the collateralSHOULD throw if
repaid
is trueSHOULD throw if
now
less than or equal tobiddingRefundExpiration
SHOULD throw if the hash of
secretC
equalssecretHashC
and the hash ofsecretA2
equalssecretHashA2
and the hash ofsecretB2
equalssecretHashB2
SHOULD throw if
borrowerLiquidatedCollateralWithdrawn
is trueSHOULD throw if
lenderLiquidatedCollateralWithdrawn
is trueSHOULD throw if
currentBid
is less than or equal to 0Compatibility
ERC 1850 is compatible with BIP 197 for atomicloans with Bitcoin and other HTLC compatible chains.
Implementation
This implementation is a simple example of a HTLPC using Solidity
https://github.com/AtomicLoans/ethereum-contracts/blob/master/contracts/AtomicLoan.sol
Note other hash functions can also be used, such as
keccak256
,ripemd160
. However both parties should specify the hash function to be used before the HTLPC is initialized.References
Papers
Standards
Discussions
Copyright
Copyright and related rights waived via CC0.