# Retriev v2.0 (Arbitrum)

### High level description of the new modular design
We assume there's a L1 chain (eg, Ethereum) and a L2 chain (eg, Arbitrum) which are able to exchange onchain messages using an existing protocol (L1<>L2 messaging: https://developer.arbitrum.io/arbos/l1-to-l2-messaging).

So the current Retriev smart contract will be replaced by 3 different contracts:

#### (1) Smart Contract on Ethereum to manage payments

- Client uses a `depositEth()` function to move tokens (ETH) in an user owned vault inside the smart contract;
- Allowed contracts (eg, Retriev and other protocols) can lock X tokens for Y amount of time using the function `lockPayment (uint256 amount, uint256 time)`;
- Providers use a `claimPayment()` function to get paid after the locktime;
- Referees use a `slashProvider(uint256 amount)` function using L2 to L1 messaging;
- NOTE: confirmation time may be quite long (1 week?)
- Referees use a `claimFees(bytes32 client_signature)` function to get payment for appeal fee, contract maintain a list of used client signatures to avoid double spending;
- [Referees use a `cancelProposal(uint256 deal_index, bytes32[] referee_signatures)` function if requested by the client to cancel a proposal and unlock the payment; L1 event;]
- Referees are in charge to check if the proposal was accepted or not (client ask this info off-chain with sign, referees check and send transaction, if allowed)
- Checks if signatures aren't used yet
- Before cancel deal contract referees checks in (3)
- A transaction on (3) is run to mark deal as canceled

#### (2) ("Retriev") Smart Contract on Ethereum to propose deals and request appeals

- Client uses the`createDealProposal(string data_uri, uint256 duration, uint256 collateral, address[] providers, address[] appeal_addresses)` -> `uint256 deal_id` function to propose deals;
- This calls (1) to lock an X amount of payment for Y amount of time;
- NOTE: This uses L1 to L2 messaging; ~15 min to go from L1 to L2; to avoid the client to have to wait we can have the provider list to L1 to see the transaction and start dowloading the file to give a "soft" off-chain acceptance to the client
- Function `createAppeal(uint256 deal_index, bytes32 client_signature)`
- L1 event, referee listen to this event to active the appeal process;
- Thus calls (1) to pay the appeal fee to referees;
- [or Here clients post the signature that allows referees to get paid.] tbd

#### (3) Smart Contract on Arbitrum to manage appeals

- function `acceptDealProposal(uint256 deal_index)`
- NFT is minted on L2;
- Deal is active (timestamp);
- function `startAppeal(uint256 deal_index)` used by referee network *after* the `claimFees` function is executed on L1.
- function `processAppeal(uint256 deal_index, address[] memory _referees, bytes[] memory _signatures)` used by referee leader or another referee with enough signatures to slash the provider onchain.
- function `slashProviderOnL1(uint256 deal_index)` here referee network post signatures that allows the client unlock the payment and slash the provider by sending a message from L2 to L1.
- NOTE: slashing will happen with a 1 week delay!

### Flow to make a deal

1. User go to (1) and deposit an X amount of ETH, these will be used to make deals
2. User go to (2) and create a deal proposal
3. Provider will wait for message going from (2) to (3) and continues by checking if deal can be accepted or not, if yes accept the deal on (3) and deal is marked as active.

### Flow to make an appeal

1. User creates a signature to unlock the fees for the referees using (1) prefix and posting the request on (2)
2. Referees goes to (1) and uses the signature to unlock the payment and the payment is splitted among all referees. If payment is wrong (underpriced) the referees don't take the money
3. Referees starts the appeal on (3) to leave an on-chain trace and process the rounds on-chain
4. If the provider is not slashed, nothing more happens; if the provider have to be slashed then referees goes to (3) and slash the provider with L2 to L1 messaging, deal is marked as inactive on (3)
5. User will receive the unlock of the funds on (1) and they will be added to the available balance