LexLocker is an escrow system designed by LexDAO legal engineers for business use cases on EVM-compatible chains.
Users might call on LexLocker to hold a deposit for the delivery of goods or services without needing bank accounts or reliance on trusted third parties to wire funds.
All that is needed is a wallet.
Everything else is handled by code in a true peer-to-peer fashion.
Let's say Alice wants to hire Bob for a quick job building her a website. She doesn't need to know Bob's name, really, just his wallet address. But anyways ....
She first takes a look at the legal forms maintained by LexDAO, like this services agreement.
Then, she attaches these terms to a LexLocker escrow deposit by calling the smart contract with the integer 1 representing the on-chain representation of this form. These terms lay out the basic expectations of the work to be completed as well as provide a fallback in the event either party tries to take this deal to meatspace court.
After calling deposit on LexLocker, the funds for the work, $2000 DAI, then automatically get deposited with the selected termination time limit (say, 2 weeks) for Bob to complete her website.
If 2 weeks passes and Bob doesn't raise a dispute by calling lock, Alice can reclaim her deposit. These are the terms embodied by the code and the withdraw function, after all.
Otherwise, if Bob does the requested job, Alice can release the funds and they will be immediately sent to Bob.
That simple. Done deal.
In addition to standard escrow, deposits can also take advantage of "defi" yield by holding tokens as BentoBox shares.
This means that the opportunity cost of payments being held idle is not lost, as payments increase for the recipient (and/or the depositor, upon claiming funds back or the resolution of a dispute).
BentoBox earnings occur through the support of flash lending and strategies.
LexLocker currently supports timed deposits for ERC20 tokens, as well as Ether (or similar native currency on EVM chains) and ERC721 NFTs.
Multiple escrows and LexLocker actions, such as releasing funds, can be combined into a single transaction through the use of multicall functionality. This also effectively allows for milestone payments.
Using the standard for off-chain signature recovery, EIP-712, LexLocker allows a receiver party to sign and request an escrow deposit without needing to spend gas. In this manner, more legal privity can be established between parties (aside from course of performance), as key signatures between both depositor and receiver are established upon the registration with the depositInvoiceSig function.
Ethereum mainnet: 0xf91e098a4da86aACf082F35F976E8eb18005b33c
Arbitrum: 0x60692a57F8b25108FcC27f21a964D05a2D39d2b5
Polygon: 0xc680eB3C6395C8Ab94Cbf3Bb46Cd7C3340481e40 ALPHA
xDai: 0x102fd5b56E89EAf0336BB7b11c0F981Aa73f4462
Javascript tests are provided that provide comprehensive coverage of expected LexLocker operations.
Users can make a deposit directed to a receiver account as well as select an arbiter resolver in the event of dispute or other problems (such as one party losing keys).
The token selected can either be an ERC20 or ERC721 NFT. In either case, if ETH is attached to the call (msg.value), this will be overriden and ETH will be assumed as deposit. Such ETH must match the value selected in wei.
Otherwise, in the case of token deposits, the selected value will be escrowed after LexLocker is approved to pull tokens from the user wallet.
Note, however, through batching support in multicall on tokens that have an EIP-2612 permit function (or DAI-derived version), the approval step can be included in a single TX, by means of the permitThis and permitThisAllowed functions, respectively.
If nft bool is set as 'true', LexLocker will be instructed to pull the value as an ERC721 tokenId.
Finally, details can be included to provide an on-chain reference for an agreement or other context parties feel might be important for course of dealing. Note, LexLocker includes an internal legal library of forms maintained by LexDAO, which may be efficienctly included as integers in this param, with the additional benefit of an immutable record key-signed by the parties.
Similarly, the depositBento function instructs LexLocker to pull ETH and ERC20 tokens and store them into the BentoBox vault as shares that can earn yield for the parties.
The bool param wrapBento, if 'true', will pull and automatically deposit ERC20 tokens into BentoBox shares, otherwise, LexLocker will complete a shares transfer from the user's BentoBox account. Note, the user should have called setMasterContractApproval on BentoBox for direct transfers to succeed, which can be combined into a single TX through multicall and the setBentoApproval function in LexLocker, which incorporates EIP-712 signatures.
An invoice pattern by a receiver can be further serviced by EIP-712 signature recovery and the depositInvoiceSig function. In this case, the bentoBoxed param represents the choice to make an integrated call to the depositBento function. Otherwise, the other params are fed into a typical deposit pattern, with the v / r / s param representing the elements of the off-chain signature for recovery.
After a deposit is made through one of the methods described above, the depositor can release funds at anytime after they are satisfied with the deliverables of receiver.
If the termination time is reached, as determined in Unix epoch time, the depositor may reclaim their funds by calling withdraw. This function will be frozen upon the call of a lock by either party (see below).
A LexLocker deposit may be frozen by either escrow party upon calling the lock function, which reserves the funds for a determination by the selected resolver. The registration param is the incremented ID assigned to each new LexLocker escrow. Parties can continue to update their claims and descriptions of such dispute or safety lock through the details param which is stamped as an event on an EVM chain.
Anyone can join the LexLocker dispute protocol as a potential resolver by calling the registerResolver function with their status (if the active bool is set as true, this confirms willigness, which can be revoked) and fee, which is the divisor to determine how much they can be paid for resolving a LexLocker dispute or safety lock.
To claim such fees, only the resolver is permitted to call release and enter their judgment in terms of a depositorAward and receiverAward split.
The 'resolver fee' is automatically calculated after awards are entered and forwarded to the resolver. Note, in the case of a locked NFT, the award must be the whole NFT, and therefore, it is an either or proposition. So, if depositorAward is a positive integer, the depositor will receive the locked NFT, but if set to 0, the NFT will be sent to the receiver (this format is for code simplicity, and also, the impossibility of splitting a non-fungible token). Clearly, in the case of NFTs, the resolver fee must be negotiated separately (but game theory suggests that something will be figured out, otherwise the resolver might leave the NFT in limbo).
LexLocker can host on on-chain registry of legal agreements to complete the picture for 'ricardian contracts', where gaps in code can be plugged by human readable descriptions of parties' intentions to instruct them, resolvers and courts in the event that something goes wrong or additional assistance is required. These legal templates are maintained by LexDAO on github as a 'LexCorpus'.
For this purpose, simple functions are assigned for adding 'strings' that can represent links or hashes to legal templates, identified by unique integers that can be included as details in LexLocker escrow deposits.
The lexDAO role can be updated, as well, as governance features are determined.
Currently, for LexLocker ALPHA, a Gnosis Safe multisig consisting of certified LexDAO legal engineers with 2/4 authority is deployed on Polygon for legal maintenance and potential inclusion as a resolver for LexLocker escrows: 0xf8DBd458f841424e2fD5fBDf18A7dEA17eb2211D. This multi-sig builds on prior experience working as an arbiter for Raid Guild escrow management, and follows the procedures set forth here: LexDAO Arbitration.