FIP Discussion: beneficiary address for a storage provider

[steven004]

Summary

To provide more flexibilities for Filecoin finance market, I propose a new role beneficiary, for a storage provider, which takes over the financial control from the owner.

Motivation

Filecoin's pledge collateral mechanism makes it a perfect lending market. We already see some projects launched to solve the problem, e.g. Coinlist is running lending business to Filecoin storage provider while asking excess pledge paid in other digital currency. However, the filecoin node itself has great value including pledge collateral and locked rewards, which, ideally, can be used as pledge for filecoin lending. DARMA project is trying to do this but asking the ownership transferred, which is also practical in some Filecoin service providers.

The problem is the owner of a Filecoin node has full control of the node, including changing worker and controllers, or terminate sectors. This proposal is to separate the node control and financial benefit into different roles, that's how the beneficiary comes in.

Design

Based on the current design, add one more role, beneficiary, to a Filecoin storage provider node, which takes over the withdraw function. Currently a rough thought, a beneficiary address has the following features to be implemented:

1. By default, the owner is the beneficiary if there is no specifically reassigned. In this case, there is no different than the current design;
2. The beneficiary address change can only be initiated by the current beneficiary address, and be approved by the new beneficiary address, just as the design for owner address change in the current design
3. (Optional) We may also want to have a security design to set beneficiary address expiry date; In this case, when a beneficiary address is expired, the beneficiary address automatically back to the owner address. The expiry date can be set by the beneficiary address and be approved by the owner.

Use Cases

Mainly there are two scenarios for the beneficiary address being separated from owner address based on the current design

1. Enable lending market using the node rewards as collateral. This is actually done by some Filecoin network service providers, but, currently, it only works when the lender is the service provider. When we have the beneficiary address, the lender could be anybody else who value the node itself.
2. For storage provider internal use, there are lots of advantages when having a separated beneficiary address, which can be controlled by the finance department, while owner be controller by the maintenance/engineering team.

But, there are more use cases can be developed when this is in place. E.g.

• Block Reward pooling design: Rewarding sharing is a very good thing for small/medium storage providers since it can provide much more certainty of income. Almost in all mining pool design, the small/medium miners need to hand over the beneficiary address to the pool provider. In Filecoin, Owner address need to be transferred if there is no another beneficiary address, which is too risky, since owner has fully control of the node. A separated beneficiary address makes it much safer.
• Reward pooling can be integrated with Smart Contract when it is available, in this case, the beneficiary address could be transferred to an trustless actor. We can not transfer the owner to a smart contract address, since it is hard to change it back. But we can do it with beneficiary address with a good design.

In addition, if we have the security feature, it will protest the storage provider from the beneficiary owner mistake (loss or expose of private key), or any other risks, e.g. bankruptcy, to some degree.

Consideration

So far, not seen security issues if we implement it correctly.
Only a little bit complex added to the protocol, but it should be fine.

You are welcome for any comments.

[ZenGround0]

Strongly in support of this. Can you elaborate on the benefits of Design.3, the automatic expiry date? This is the part of the proposal I am least sure about.

[anorth]

This sounds like a promising direction, though a few things are still unclear. - Can the owner address change the beneficiary, or only the beneficiary? i.e. is the beneficiary assignment revocable? - In either case, I think we need to work through the incentives in case the owner and beneficiary become mutually hostile, so we all understand what can be guaranteed. - I don't quite understand "pledge collateral and locked rewards, which, ideally, can be used as pledge for filecoin lending". Are you suggesting that the locked funds could be used as collateral, implying the collateral holder has first right to them? If the operator gave away all financial benefit, what incentive would they have to operate the node effectively?

…

On Tue, 30 Nov 2021 at 04:23, ZenGround0 ***@***.***> wrote: Strongly in support of this. Can you elaborate on the benefits of Design.3, the automatic expiry date? This is the part of the proposal I am least sure about. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADMW6QO6BMAKS6JGU4KDM3UOOZKBANCNFSM5I6MAKWQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[steven004]

Strongly in support of this. Can you elaborate on the benefits of Design.3, the automatic expiry date? This is the part of the proposal I am least sure about.

Let's think about one scenario, a lending capital company (L) may sign a contract with a storage miner (P), in which L lends FIL to P as pledge for power growth, while taking the future block rewards as collateral. L would like to take the beneficiary address for a certain period of time, at the same time, lending FIL directly to the miner node incrementally as designed in the contract. At the same time, the L (and P) are both taking the risk of node failure for some uncontrolled reasons.

In this case, an expire date could protect P to take the beneficiary back when the contract is closed.

One may ask how the L protect itself? as mentioned above, an incremental lending policy might work, and interest rate is another tool to get benefit, of course, against the risk too.

[steven004]

@anorth

• Can the owner address change the beneficiary, or only the beneficiary? i.e. is the beneficiary assignment revocable?

I would propose only beneficiary can change beneficiary, the owner can not. But the mechanism would be as the current owner change, which is: the currently beneficiary propose a new beneficiary, and the new beneficiary approve it. It means two steps required, two methods needed. So, that is revocable.

• In either case, I think we need to work through the incentives in case the owner and beneficiary become mutually hostile, so we all understand what can be guaranteed.

That's why I think the expiry date is one thing worth to be considered, which provides a way to solve the problem when the owner and beneficiary become mutually hostile. Of course, they will design their contract with this in mind.

• I don't quite understand "pledge collateral and locked rewards, which, ideally, can be used as pledge for filecoin lending". Are you suggesting that the locked funds could be used as collateral, implying the collateral holder has first right to them? If the operator gave away all financial benefit, what incentive would they have to operate the node effectively?

Many storage providers need borrow FIL to commit more storage or save more data into filecoin network. In the real world, Filecoin is different than other digital currency lending, some lending companies is actually asking to take the node ownership or beneficiary as collateral, and many storage providers already accept this. We already see some cases like this even though the ownership is still a barrier.

Another thought is for DeFil, when a smart contract is built for deposit and lending, we will build up a decentralized low-risk low-interest trustless lending market. Storage providers will not need to worry about this any more.

[jennijuju]

Many storage providers need borrow FIL to commit more storage or save more data into filecoin network. In the real world, Filecoin is different than other digital currency lending, some lending companies is actually asking to take the node ownership or beneficiary as collateral, and many storage providers already accept this. We already see some cases like this even though the ownership is still a barrier.

Another thought is for DeFil, when a smart contract is built for deposit and lending, we will build up a decentralized low-risk low-interest trustless lending market. Storage providers will not need to worry about this any more.

IMHO Defi use cases should be built on top of the network, via layer 1/2 instead of natively in the protocol cuz - is it what Filecoin Protocol is for? In addition, it's hard to have a design that works for all use cases, and it might be less feasible to make protocol changes every time a new use case coming up. So for more specific lending programs, I think FVM will unblock more possibilities there.

That being said, I'm also in strong favor of this FIP as SPs have been wanting to be able to withdraw rewards/miner balance to a non-owner address. The reason is they'd like to have the majority of funds kept in a separate wallet(like cold wallet), instead of the owner address, which they constantly keep on the node for operations. Right now they have to pay double the gas fees to transfer the funds to withdraw the balance from the actor, then transfer the funds from owner to the desired wallet.

I think it's better for the owner address to be able to add and remove beneficiary accounts - to be consistent with that "owner address is THE key you need for all your miner operations - don't lose or give it up!".

[steven004]

Agreed. DeFil is built with a smart contract, or even in layer 2. This proposal is not to build DeFi directly, but make DeFi over Filecoin doable. The DeFi here we are talking about is not only the token exchange, but supporting storage providing as well collaboratively.

One of the main purposes of this proposal is to let a storage provide could pledge the future income to get the currently required investment without losing all control of the node. That is also why the beneficiary need to be separated from owner, and can not be controlled by the owner, since it will lose the function as a collateral to get investment if the owner could change it arbitrarily.

[AthenaPoolOfficial]

There are two questions that need to discuss：

At first,is there only one beneficiary address being set？We may need to consider the proportion that the beneficiary hold. Rewarding benefits may not be fully transferred to the beneficiary, especially when the owner and beneficiary have a complicated loan relationship. Is it necessary to set up multiple beneficiary addresses and distribute different rewarding proportion to different beneficiaries?
Secondlly, we approve your idea of the Design.3 .Considering the rewarding benefits of the beneficiary should not be unlimited, we can desgin a incentive to ensure that the owner can reclaim the ownership after the contract expiring . However, the beneficiary may be dissatisfied with the reward because of the node failure and the fluctuation of network during the benefits period. Let's think in just a little different way, like setting the maximum reward limit of the beneficiary. Once the rewarding benefits is enough to offset the appointed amount, the beneficiary address will be recovered automatically, but this approach requires a consensus on the criteria of rewarding benefits.

Actually, under the current version, it seemed possible to use the multiple signature in owner wallet address to achieve this idea , any operations of the node owner need the signature from relative party，which can ensure benefits of all parties.

[arajasek]

This seems like a promising idea to me.

[Stefaan-V]

Very supportive of this!

[fhmd4k]

I very much support this proposal.

Otherwise, there will be no benefits to investors who hold filecoin for a long time, and as the output is much larger than the amount of pledge and destruction, the filecoin held by the holders will depreciate more and more, and even negative returns will appear.

Some new entrant small investors are also unable to build their own participation in mining.
Although there are some third-party companies in China that build a mining pool-like model and divide the income according to the investment ratio, this behavior is very risky, because the pledge and income provided by investors are not regulated and may run away at any time.

[jennijuju]

One of the main purposes of this proposal is to let storage provide could pledge the future income to get the currently required investment without losing all control of the node. That is also why the beneficiary need to be separated from the owner, and can not be controlled by the owner

The beneficiary won't have any control of the node anyways, b/c main operations like adding new sectors, making deals, proving sectors and terminating sectors are still controlled by worker/ control/owner address, which owner address has full control with.

I still think it's very important that owner has some level of control over beneficiary account as an administrator, which was also agreed by some SPs from the Asia storage provider working group during the call today. One of the reasons being it provides a layer of security to the miners, as if the beneficiary(which like you said, can be an investor has no experiece/skills to keep the key secure) lose the keys for the wallet and the owner can't update it, all the rewards wont be withdrawable from any account.

One possible solution for this can be: the owner will need a signature from the beneficiary for executing the beneficiary account removal.
this might be a bit over-complicated, but it may potentially be implemented as, the beneficiary account must be a msig account shared between owner and end beneficiary wallet. By default one of the two accounts needs to propose the withdraw and the other needs to approve the withdraw. If the owner is willing to give up control over the beneficiary, they can remove themself as a signer of the msig

[steven004]

I would think the protocol level should be simple and flexible. Lots of configurations can be done in the real deal. We may think too much on practices. I'd love to provide the framework and mechanism for users who could do lots of things, and we can have practical guidance for people to follow.

In this case, just as we do for owner, It might be better to let user choose if the beneficiary is a single/multiple signature address, but we should allow multisig address as beneficiary in design.

When it comes to how beneficiary address can be changed. This one is really hard. One reason is that we do not want the owner to take full control, since it makes beneficiary loss its value for collateral (the owner can take it back any time). If the owner has half control, but how? maybe every time beneficiary address change has to be approved by owner? it could be a solution, but does not solve the key loss problem because the beneficiary private key is needed for changes too. Do we still need to design an expiration criteria, by date or/and by withdraw quota? this is also one option.

Any opinion, guys?

[Fatman13]

Cool idea! Very supportive of this!

One thing might be a bit off-topic here is that apps like https://filpoll.io/ need to be aware of owner signing the vote to prevent double vote by a beneficiary address.

[anorth]

@steven004 I'm convinced by your design. I think supporting multisigs as the beneficiary can answer most of the concerns about distributing rewards, backup control mechanisms etc. In the future (with FVM), the beneficiary can be an arbitrary contract which means it could be composable, like an ERC721 or similar.

I look forward to an implementation draft.