Q: How can OPF send OCEAN from multisig + HW wallets? (Web interface? Other?)

[trentmc]

Summary

Overall goal: Ensure that DF flow works where hardware wallets can fund OCEAN etc

Details

Here are the smart contract steps wrt paying rewards:

1. OPF approves for DFRewards.sol to spend OCEAN. Call token.safeApprove(contract_addr, sum(values))
2. OPF tells DFRewards.sol how much OCEAN each LP gets. Call DFRewards.allocate(tos, values, token_addr). Since there are thousands of LPs, it will batch this.
3. Then, each LP claims

This issue is about step 1.

How does OPF do this approval (step 1)? OPF will be holding the funds in a multisig (gnosis safe) wallet, and signers typically have HW wallets.

Options: [May 18]

• Candidate 1: do it from CLI with HW wallet. Brownie supports HW wallets via clef. Steps: (a) install geth (b) follow instructions in brownie. CON: geth works for eth mainnet, would need something else for other chains we support. CON: need to install geth, it's heavy
• Candidate 2: web interface to allocate OCEAN to DFRewards.sol contract. CON: will take a bit of time to build. PRO: once it's built, it will be the slickest.
• Candidate 3: send a weekly amount from HW wallet to a wallet with private key as envvar, then run dftool from there. CON: slightly dangerous, but only briefly. PRO: can do readily

[added May 19]

• Candidate 4: change step 1 from doing token.safeApprove() to doing a simple "ERC20.transfer()". We know we can send directly from Gnosis safe.
• Candidate 5: the token.safeApprove() is constructed and put into Gnosis Safe multisig to sign. Then the web interface = Gnosis multisig. Then the question is: how do we construct this "allocate tx"
• Candidate 6: do token.safeApprove() from etherscan. (Can this be with gnosis safe too? Eg is etherscan an "app" in gnosis safe?)

Discussion: May 18:

• If we only need to do step 1 (and not step 2):
  • Candidate 1 is heavy / painful. Candidate 2 is pretty good (if just step 1). 3 is ready now but slightly dangerous.
  • Of these, cand 2 is best

Discussion: May 19:

• Added Candidate 4, 5 6. Candidate 4 is simpler/better yet. 5 and 6 even better, we get a gui-based portal using off-the-shelf tools:)
• BUT! DFRewards.sol expects the same address to do both step 1 and step 2. It could be otherwise, but security issues arise.
• Therefore we need a solution for both step 1 and 2.
• Analysis:
  • Candidate 1 still heavy / painful
  • Candidate 2 will require huge complexity for handling failed txs, etc. LOTS of work, devil in the details
  • Candidate 3 is ready now, and super useful for debugging
  • Candidate 4, 5, 6 don't work because they're really for step 1.
• Therefore: candidate 3 is the way to go
• Which means: no more work for this issue, just ensure that ops reflect it

[idiom-bytes]

[trentmc May 19: this comment was given when "Candidate 2" was still the leading candidate. But now we're doing "Candidate 3"]

---

Began implementing an "Admin Portall" w/ an Allocate dashboard.

• Signer needs to select network
• Signer needs to select token
• Signer needs to load rewards.csv file they want to use.

TODO:

• [ ] Errors w/ calling contract via RPC at the moment
• [ ] Implement batching, error handling, and provide functionality to resume TX's
• [ ] Provide shortened 0x addresses for airdrop contract + token that will be used as a way for us to verify before allocating
• [ ] Improve UX/UI so elements/information is displayed nicely

There is currently no security or permissions around this. Anyone can access this page. I have also taken the liberty of adding a link to the navbar.

[trentmc]

May 19 update:

• added candidate 4, 5, 6
• But we really only need to do step 1 and 2.
• Re-analyzing: candidate 3 is best
• Therefore nothing else to do for this issue, we can close

(I updated the description to have more detail)

[trentmc]

Reopening, because it would be really nice if:

• DF partners could approve funds via their HW wallet
• OPF could allocate funds via a gnosis safe multisig (with >=1 HW wallets behind)

[trizin]

I was able to use an HW wallet with Brownie.

Here are the steps:

• Install geth - this will also install clef.
• Launch clef in terminal 1
• Connect hw wallet to pc
• Call brownie.network.accounts.connect_to_clef() function in terminal 2
• Accept the connection request from terminal 1
• To access the accounts in hw use: brownie.network.accounts

[trentmc]

Q: how to do a flow with gnosis safe multisig? A: the key is ape-safe. Here's the quickstart:

from ape_safe import ApeSafe
safe = ApeSafe('ychad.eth')

dai = safe.contract('0x6B175474E89094C44Da98b954EedeAC495271d0F')
vault = safe.contract('0x19D3364A399d251E894aC732651be8B0E4e85001')

amount = dai.balanceOf(safe.account)
dai.approve(vault, amount)
vault.deposit(amount)

safe_tx = safe.multisend_from_receipts()
safe.preview(safe_tx)
safe.post_transaction(safe_tx)

Flow where OPF spends the Ocean. Steps 1-3 do approve, steps 4-6 do allocate.

1. Via dftool, someone create OCEAN.safeApprove(contract_addr, sum(values)) tx
2. Via dftool, someone posts the tx to gnosis safe
3. Inside Gnosis Safe app, >1 OPF people multisig-sign the pending tx
4. Via dftool, someone create DFRewards.sol::allocate() tx
5. Via dftool, someone posts the tx to gnosis safe
6. Inside Gnosis Safe app, >1 OPF people multisig-sign the pending tx

[trentmc]

From some slack discussion...

[Berkay] Wouldn't it be simpler if: Multi sig transfers tokens to hw wallet Hw wallet calls allocate func

[Trent] Yes it's simpler

[Berkay] Do you think there is a security risk this in this approach?

[Trent] I had suggested the multisig because

1. More secure yet. Though hw is very good tbh
2. Flexibility: it's really easy to pass control among various addresses. Eg start out with a 1/1 multisig signed by a hw wallet. Later on if we want to have more control among more people, it's easy to do

Tbh I'm on the fence wrt this being worth it

Also, I'm not sure how well Gnosis safe will even support some of the chains

[Berkay] right + we will need to do it every week for each chain, might get complex to manage

[Trent] Good point!

And like mentioned, we can always re-deploy news contracts much later on. We'd probably do that when we automate more fully. That would be in 2023 sometime

To summarize: you're right. Just hw wallet is simpler. And will serve our needs for now. And we have a way to migrate later.

[Berkay] I fully agree, I wish there was an easy way to make it automatable and secure at the same time

[trentmc]

I just added instrs for HW wallets into df-py README

https://github.com/oceanprotocol/df-py/commit/09dca5f4dbbd15ec8065e99b6ec936dc072f0dda

We can now close this issue

[trentmc]

About multisig wallet:

• Assume that it holds required OCEAN funds, and funds for gas (ETH, MATIC, etc)
• This is OPF Multisig in Gnosis Safe. https://github.com/oceanprotocol/atlantic/blob/master/logs/wallets.md

Options / Steps

Below are three options (A, B, C), and the corresponding steps. Pre-step for all options:

• inspect rewardsperlp-OCEAN.csv to see how much OCEAN each network needs

Option A. Multisig -> Local account

1. Generate local account via dftool newacct. Remember private key & address.

2. For each chain: 2.1 tx: from multisig, send OCEAN -> local account https://github.com/oceanprotocol/atlantic/blob/master/logs/wallets.md

   2.2 check: does local account have funds for gas. If no: tx: from multisig, send funds for gas-> local account

   2.3 tx: from local account: dftool dispense

Option B. Multisig -> my hw wallet

1. For each chain: 1.1 tx: from multisig, send OCEAN -> my hw wallet account https://github.com/oceanprotocol/atlantic/blob/master/logs/wallets.md

   1.2 check: does my hw wallet account have funds for gas. If no: tx: from multisig, send funds for gas -> my hw wallet account

   1.3 tx: from my hw wallet account: dftool dispense https://github.com/oceanprotocol/df-py/blob/main/README.md#usage-hardware-wallets

Option C. Direct from Multisig

1. For each chain:
   • tx: from multisig: dftool dispense

Analysis Chosen approach: A for now

Steps for chosen approach

0. inspect rewardsperlp-OCEAN.csv to see how much OCEAN each network needs
1. Generate local account via dftool newacct. Remember private key & address.

2. For each chain: 2.1 tx: from multisig, send OCEAN -> local account https://github.com/oceanprotocol/atlantic/blob/master/logs/wallets.md

   2.2 check: does local account have funds for gas. If no: tx: from multisig, send funds for gas-> local account

   2.3 tx: from local account: dftool dispense