Locked.fyi Dao & Hook Update

[nfurfaro]

DAO

• Using: "Open Enterprise" template
• It includes all the apps we want (as well as some extras) out of the box, except for the "Agent" app: https://www.autark.xyz/apps
• It is straightforward to install the Agent app with the aragon cli.
• Edit: Now that I've got the cli working, I think we should use the "company" template, and just add the rewards app. We get just what we need and nothing extra with this approach, which makes for simpler Dao management.

Hook Contract

needs a few minor tweaks:

• [x] no minting to zero address
• [x] check length of the data
• [ ] possibly add call to lock to withdraw?

Remaining Issues

• [ ] withdraw from lock to Dao
• [x] agent app installation
  • I managed to install the agent app on the rinkeby deployed dao using the aragon-cli !
• [x] Ensure that minting works as expected.
• [ ] Ensure that rewards distribution works as expected.
• [x] Set the correct beneficiary address (the "vault app)

Deployment & Verification

We're using the buidler-deploy plugin for deployments, and the buidler-etherscan plugin to verify contracts. Documentation for these can be found here:

• https://github.com/wighawag/buidler-deploy/tree/master
• https://github.com/nomiclabs/buidler/tree/master/packages/buidler-etherscan

cc @julien51

[nfurfaro]

@julien51 Here's a bit more detail on the remaining issues.

---

1.) Withdraw funds from lock.

We need to decide if this can be a manual process, or if it should be automated.

If manual, we have 2 options: a.) Someone will need to use the agent app to call withdraw on the lock each month. b.)Someone would need to be made a lock-manager, and will need to call withdraw directly (not using the agent app) on the lock each month.

If automated, one possible solution is to have the hook call withdraw after each key purchase. Pros:

• automated, no need to remember to call withdraw each month.
• the hook is already a lock manger.

Cons:

• would add to the gas-cost of the purchase function.
• the lock would have no funds remaining for refunds, as the Dao (agent or vault) would hold all the $DAI.

---

2.) Distribution of rewards to shareholders.

• setting up a reward is pretty straightforward, except for the "amount" parameter.
• The UI expects a fixed token amount, which then gets split proportionally amongst the shareholders each month (or other distribution period).
• We probably want to distribute the entire balance (or a set percentage of it) each month, rather than a fixed amount.

Challenges:

• requires deploying a custom version of the rewards contract. The standards one is deployed behind a proxy and is also an "Aragon package". I could try to simplify this and just deploy a single modified contract and use it directly.
• When a member claims their reward, the Dao's DAI balance would be used to determine the total amount to distribute. But, this would be different for each member who claims a reward (due to both additional withdrawals from the lock, and previously claimed rewards). Ideally we snapshot the Dao's Dai balance at the block when the reward becomes claimable for the month (probably when the first member claims their reward), and use this value for the rest of the reward calculations for that month.

Simplfied solution:

• We choose a reward amount which is less than the expected monthly revenues from the lock.
• we set the reward duration to be relatively small, say 3-6 months, and then review the reward amount for the next reward.
• if Dao.balance > reward.amount, there will be some Dai left over in the Dao for next month.
• if Dao.balance < reward.amount, reward distribution will fail for that month. The funds will still be held by the Dao, and the next reward amount could be adjusted to distribute the extra funds. Pros: It works now and we could deploy to mainnet very soon. Cons: Lots of manual steps, but they can be performed by any member of the Dao. Maybe a Dao member could act as a "Dao manger" and be compensated with extra shares (can be minted via the Dao UI as needed with a passing vote)

alternately, the "Dao Manager" creates a reward at the end of each month based on that months revenues.

[julien51]

Thanks for this @nfurfaro !

Another idea that I just had: we should use the hook to withdraw... but only when the price changes. This has several benefits:

1. It does not happen that often (so gas cost is limited, except for these times)
2. We can now have a "fixed" amount to distribute (since we know how many keys have been sold to get to the higher price), and the price for each of these keys.

I believe this has also the same advantages that you highlight.

1. The amount is "known" (we can compute that because we know when the price and the number of keys which have been sold since the last withdraw). For cancellations, we should keep say 10% in the lock.
2. The duration should be relatively consistent. Even though the price increases faster in the beginning, there should be less transactions... and later it is the opposite.

What do you think?

[nfurfaro]

@julien51 I like the idea of using the hook to withdraw only on price changes to limit the calls and gas. I think the hook is our best option for the withdraw action as its automatic.

For cancellations, we should keep say 10% in the lock.

sound good.

I'm not quite sure I follow your logic on the second part though...

The amount is "known" (we can compute that because we know when the price and the number of keys which have been sold since the last withdraw)

We basically have to set up the withdrawal schedule (eg: once a month for a year) and the amount (one fixed amount for each withdrawal). We can only calculate the lock's revenues if we know how many keys have sold, which we can't know until after they sell... but I may be missing something here.

Here's a screenshot of what it looks like to set up a new reward:

[nfurfaro]

Another low-tech way to do this: We hold off on distributing rewards for a set period (ie: 3 months)as a buffer. So, no rewards distributed for Aug, Sept or Oct Then we set up a new reward to be distributed monthly for Nov, Dec & Jan, the amount being average of the total revenues for the previous 3 months. So the reward amount is always known as it's for past revenues, averaged out over a number of months This could be done on a 6-month interval instead to lessen the management work, but it's pretty minimal regardless.

cc @julien51

[nfurfaro]

TODO: look into this: Can the hook create a new reward (IE: one time disbursment) ?

[julien51]

I think this is mostly stale. Closing.