zerodao-finance / zero-protocol Goto Github PK

Implement a function to be called onlyUnderwriter in the ZeroController which should measure gas usage from start to finish, send a tx to IModule(module).receiveMeta(from, asset, nonce, data), get the on chain value of gas usage in terms of renBTC, apply the same fee as a loan, then send a tx IModule(module).repayMeta(gasValueAndFee), and compare balance before and after to confirm that renBTC (or whatever asset is) acquired is greater than gasValueAndFee, then depositAll() to increase the value of zeroBTC proportionally by sending renBTC into the vault.

average(gasValueInETHWithoutFee, gasValueInETHWithFee) should be repaid to keeper via permissionedEther the same as in a loan transaction, so a keeper can benefit in native currency

The function signature should look like

function meta(address from, address asset, address module, uint256 nonce, bytes memory data, bytes memory signature) public onlyUnderwriter

The JS SDK library should feature a MetaRequest class designed with similar structure to the TransferRequest, which should do all of the heavy lifting for implementers wishing to make use of zeroDAO to incentivize keepers to forward tx execution on behalf of an end user

Keeper process should be a dockerized image that accepts a private key or mnemonic then spawns a listener for transfer requests, and has the ability to validate then dispatch a loan execution, then subsequently wait for a repayment event from RenVM to call the repayment function

Write test to confirm the loan repayment works properly via the Swap module

Write a zeroDAO module contract which should accept an ABI encoded (address[] memory path, uint256 amountIn, address recipient, bytes memory callData) as its data parameter, and the collateralization requirement should be set by governance but initialized at 10%

receiveLoan should handle executing the trade, then hold the output token in the module contract, storing the necessary details to reverse the trade in the event of a liquidation in a storage struct.

repayLoan should release the funds to the recipient then do a low level call to the recipient with callData as input

If callData is 0x then simply transfer the funds to the recipient and exit

If callData is not 0x then the module should approve the recipient to transferFrom the output token for the value of the output, then send a transaction with callData passed as input to the target contract with 200000 gas

Guard against reentrancy

defaultLoan should be implemented to reverse the trade execution and return the renBTC recovered to the vault, allowed after a certain number of blocks (parameter set by governance). To maximize returns and protect against griefing, the UniswapV2Library.sol library should be used to call getAmountsOut on two paths: the original path used to trade in reverse, or the direct path from the two tokens with WETH used as the middle point. The result is we should have a sane default to fall back on if the inverted path is suboptimal when the default occurs

Write a deploy/3_deploy_mocks.js that will only run when FORKING=true, which should mint renBTC using the mocked renBTC and seed the BTCVault.

The script should transfer the mock zeroBTC into the ZeroUnderwriterLock at the address returned from await zeroController.lockFor(trivialUnderwriter.address)

To confirm it worked, launch the zeroBRIDGE application in dev mode and run a test transfer

Logic required on the client should be kept in the sdk in lib/zero.ts where possible, unless it is specific to the sushi implementation

Logic should include facilities for broadcasting transfer request to libp2p, checking the deposit address for a successful deposit, watching for the execution on Ethereum, and waiting for repayment of loan

Abstract in a way that is similar to 0confirmation/packages/0confirmation-sdk

Fix errors occurring at the smart contract level when executing the loan function on ZeroController

Test should complete signifying that the funds successfully transfer

Write script where we can abstract complex multisig txs and sign with private key set with the WALLET environment variable

Use ethers.js and @gnosis.pm/safe-service-client

Example usage:
yarn hardhat run scripts/multisig.js --network matic --data --to DelegateUnderwriter --value 0

The --to flag should use await hre.ethers.getContract(to).then((v) => v.address).catch(() => to) to attempt to resolve a name to an address but fallback if it is an address

For the calldata arg we would just use backticks with @ethersproject/cli like --data $(ethers eval 'new Interface(['function addAuthority(address, bool)']).encodeFunctionData('addAuthority', ['0x...', true])')

The goal us for us to paste a complete command into team chat, and when we run the script, it should either propose it to gnosis or it should sign a proposal that already exists with those params

The depositAll() function is currently a stub but it should handle the interaction that transfers the renBTC to the correct location

The path the renBTC must take is: vault deposit(uint256) -> controller accepts renBTC and sends it to strategy after looking it up through the standard YFI API -> strategy receives renBTC then executes its rebalance function to make sure the portfolio is in correct proportion

Use the standard approach used by any YFI vault implementation to accomplish this final features

Additional features

• Whitelist
• Make it upgradeable
• Make sure the valuation that people get when they deposit or withdraw from the vault does not change when funds are loaned

Concerns

• Swapping vaults will have to be done seamlessly if we do it

How-To

• Fund separate underwriter with new vault token
• Run new keeper for the underwriter
• Update client with new underwriter address
• Pull the original underwriter, liquidity, etc.

Modification of TrivialUnderwriter to elect a set of keepers which are authorized to send loan / repay transactions.

Adding/removing keepers should be onlyOwner

Modify deploy script so the underwriter can be tested against.

SDK interface should remain the same, rename TrivialUnderwriterTransferRequest to StandardUnderwriterTransferRequest so it is not confusing

To ensure that the end user does not end up with more funds than are actually paid out in the end by the RenVM signature, account for fees as they are determined from the respective Gateway contract by calling into the RenVM system onchain, and then account for the constant fee that is tacked on to every renVM mint.

Leave this as a parameter that can be set by governance for now, ignoring the possibility of deriving it from transfers automatically.

Reference the original 0confirmation/0confirmation repo to see the Docker image made for this purpose

The issue with the previous deployment was the failure to use network_mode: 'host' on the service definition, thus creating an NAT issue where WebRTC could not accomplish hole punching for users on a VPN (or mobile)

1. Go to https://element.io
   

3.

4.

5.

6.

7.

8.

9.

10. I need your id once you register to get you an invite.

11.

12. Eventually we will be able to connect Telegram accounts and then exclusively send Telegram messages through Matrix, but I got accounts banned when I was configuring it. I'm getting direction from some Matrix bridge devs on how to get around Telegram's detection. Currently DO NOT try to connect your Telegram account.

The libp2p connection should be able to be constructed by a function exposed by the top level require('zero-protocol').createZeroConnection which returns a require('zero-protocol').ZeroConnection instance, a subclass of the libp2p object which should contain functions:

keeper mode:

• advertiseAsKeeper(address)
• handleTransferRequest({ peerInfo, TransferRequest, signature })

user mode:

• subscribeKeepers() (begin collecting keeper objects { peerInfo, address } store in memory)
• unsubscribeKeepers() (stop collecting)
• publishTransferRequest(TransferRequest) (wait to have one keeper in cache at least, dial directly to all keepers, wait for acknowledgement of tx dispatch)

For all functions in ZeroConnection class, implement a way to construct a mock connection with the MockZeroConnection class, a subclass

The idea is to be able to test locally without a true p2p connection

Hardhat has an issue when RenVMStrategy attempts to call Curve.get_dy

Attempt a test on ganache via

yarn hardhat test --network localhost

Requires making the RenVM contracts respond to signatures we create. The best way to do this is to evm_setStorageAt the slot that holds the shard's address which is authorized to sign RenVM mint payloads

The hardhat node used for testing when yarn node:arbitrum is run is freezing when zeroBRIDGE communicates with it, regardless of whether it is done through MetaMask or a raw JsonRpcSigner on http://localhost:8545

Write a zeroDAO module contract which should accept an ABI encoded (address[] memory path, uint256 amountIn, address recipient, bytes memory callData) as its data parameter, and the collateralization requirement should simply be 100%

0.1% of the received renBTC should be charged as a supplementary fee which should be deposited into the BTCVault and the resulting zeroBTC be sent to the ZeroUnderwriterLock contract associated with the underwriter, retrieved from IZeroController(msg.sender).lockFor(underwriter)

receiveLoan should handle executing the trade, charging the extra fee, then releasing the funds immediately. If callData is not 0x then the module should approve the recipient to transferFrom the output token for the value of the output, then send a transaction with callData passed as input to the target contract with 200000 gas

Guard against reentrancy

If callData is 0x then simply transfer the funds to the recipient and exit

repayLoan should be a no-op. We would like to just execute the trade eagerly

zerop2p needs to emit transaction objects so the ZeroUser requests can send back receipts. The UI needs to show tx hashes for burns/transfers. The UI should be able to show the BTC txhash and the Ethereum txhash for all interactions the keeper or RenVM does.

Ref:

• publishTransferRequest needs to return an object { loan: Promise, repay: Promise }
• map the transferRequest to the PeerInfo in memory on the keeper And dial the transfer request sender on /zero/1.0.0/loanDispatch or /zero/1.0.0/repayDispatch to send the JSON for the transaction then construct it with ethers.js

keeper process should be able to deal with either one of these in addition to TransferRequest and the keeper process run by the DAO must be relaunched.

Inquire about access details to restart the DAO-managed keeper

The deployment logic should be replaced with a single script that handles each network properly and will properly deploy mocks/test fixtures for the test suite to run, when the deployment is using hardhat network. Deployments should --export-all to deployments/deployments.json and applications which depend on imports from the singular JSON files need to be adjusted to import only from deployments/deployments.json (zero-app/zeroBRIDGE)

npm scripts should be rewritten to use --export-all properly. If there's a way to do it in the hardhat runtime directly without needing to supply this flag, so the --export-all behavior will occur on yarn hardhat node, then implement it in the hardhat config file instead.

After revisions, console output should be clear and demonstrate each step of the process in a way that is concise and easy to understand for the developer

All calls to deploy should be replaced with deployIfDifferent so there is no more inconsistency in a deploy process. It should all be handled by yarn deploy when a deployment is needed.

The Polygon contracts are outdated and contain some errors. Pull funds from vault and launch from scratch.

SDK should include functions for the following:

• Use ren-js to compute deposit address for a given TransferRequest

• Use lib/rpc/btc to check deposit address for a successful deposit

  • Add facilities to poll the deposit address until this occurs

• Implement way to supply your own adapter to persist TransferRequest to localStorage, redis, or whatever, depending on environment, in order to resume a RenVM mint in the case that it is interrupted

  • Abstract this concept into a base class and give an implementation of the LocalStoragePersistenceAdapter and MemoryAdapter (only persist in memory) for now

• Submit RenVM compatible payload to the RenVM network, assemble payload from a TransferRequest then send it up to RenVM via the ren-js SDK

• Compute RenVM mint transaction hash

• Query transaction hash for RenVM mint to retrieve the different parameters to the repayLoan function (which are passed down to the Gateway.mint function in this function call in ZeroController.sol)

• Use libp2p network to broadcast a TransferRequest object to be received by a keeper

• Function which accepts a providerOrSigner object and returns an object of ethers.js Contract instances for each component of the system

Create mocks for RenVM network for the functions which it queries, create mocks for BTC RPC adapter to simulate a deposit being made, then implement a test suite by extending test/test.ts to simulate the entire workflow locally using the libp2p adapters as well