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.

[steven004]

The Venus team is working on the implementation, will submit a PR when it is ready for review.

[kaitlin-beegle]

Note: the FIP draft is quite promising, and multiple design iterations have been committed. The draft FIP has now been merged into the repo as FIP0029; community deliberation and FIP refinements remain ongoing.

As noted by @anorth on the initial pull request, it may be worth incorporating GetProposedBeneficiary command so that the UI can read and confirm the order.

@steven004

[steven004]

@anorth , regarding GetProposedBeneficiary and GetBeneficiaryInfo request, I am still thinking if there could be a system level method to read an actor's state. Theoretically, it should be possible, e.g. in the current implementation, we could use GetActorCodeCID to get an actor's code, and then call StoreGet to get the state.

Of course, this is not an explicit or convenient way to get a particular piece of an actor's state. We still need to implement the GetXxxx methods to make things easier. But still want to discuss if there is another way to do it, and I am afraid that some other system actors also need to add Get methods too if there is no system level call to get states.

[anorth]

I do not think we should add an ability for one actor to read another's state, except through an API published by that actor. This is a fairly strong opinion, though I would welcome a discussion (new thread) about the benefits and costs of doing so.

Yes, absolutely most other system actors need to add a bunch of Get methods to expose data to user contracts. I'm working on this.

[steven004]

Thanks @anorth.
I was bringing this up for discussion. And, I do not have a good design in mind to do it. I do not have a strong opinion whether there should have or not system calls to get an actor's state, since I do not have thorough thought and a good design to do it. Thus, I have no problem to implement Get methods in actors.

Regarding GetProposedBeneficiary and GetBeneficiaryInfo, let's add them in when other logics looks fine.

[jnthnvctr]

Apologies if this is not the right place - but wanted to throw out a thought:

• Do we need to also have some ability to tune who has the right to terminate sectors?

As I understand most of the centralized loans, one component of them is having the right to terminate sectors that have been faulting for N days to protect loaned capital. Without this component, I think it might be hard for the DeFi equivalents to spring up as the risks will be higher (or perhaps would look like rocketpool where SPs are required to source at least half the collateral)

Seems like this might be something that needs to be protected in both directions:
(SPs will want to ensure a beneficiary is not prematurely terminating sectors at the expense of clients, beneficiaries may want to ensure that past a certain date)

[jnthnvctr]

maybe just to add in (maybe implied in the above!) - i think the way we want to design both of these changes (for beneficiary address, this terminating use case) - is with smart contracts in mind, so folks can design different logic around how payment flows in/out and termination use cases.

[jennijuju]

I agree - if the control address can be a smart contract may resolve this use case ?

[anorth]

@jnthnvctr would you please start a new discussion for this? I'm familiar with this use case as part of a general desire for ACLs on worker/control addresses. I think it needs more consideration that side-caring into this FIP will allow.

[steven004]

Agreed to start a new discussion for this. This is more complicated than the initial thought we just simply separate the beneficiary from the owner, and the owner has full control of others.

[Fatman13]

Could this be another potential use case for beneficiary address?

[steven004]

Yeah. The beneficiary with smart contract will enable some financial use cases, the insurance could be one of them.

[zixuanzh]

I am not against this FIP but I am not sure if we should pass/implement this FIP at the moment (prioritization)

• Lending or various capital structure for SPs works today.
• Making this change will not materially improve the status quo.
• However, it will introduce operational overhead to existing providers (contracts need to be re-sign, legal teams need to re-review, ops team needs to learn new stuff) with little gain.
• Moreover, this puts more power in the hands of storage operators (SPs) in the event of dispute. Currently, many lenders maintain full control of the miner actor and there are also many ways that storage providers can go rogue and incur a loss for capital providers. Having full control on the Owner Actor is a good deterrent.
• However, one can further argue that this optionality is preserved since people do not have to use a beneficiary address but I honestly don't think it's adding much value and we should prioritize higher value things.

[jennijuju]

ah missed this comment!

From an engineering perspective - FIP0029 was accepted in May, and implemented in July thus it's ready to be finalized in a network upgrade. So the engineering resource prioritization concern you have doesn't apply here imho.

[jennijuju]

there are also many ways that storage providers can go rogue

please elaborate with some examples!

[jnthnvctr]

@zixuanzh perhaps your comment is outdated - but see my comment here: #253 (comment)

I think the short answer is that this FIP gets us an incremental step closer to a more flexible world, but not fully there for enabling permissionless loans (which implicitly will require mutually agreed upon terms, enforced neutrally). Anyone issuing loans today still would likely need to have some sort of joint control of a miner (e.g. in the case of how terminations are handled).

This is a good reminder to resurface the control actor discussion because I think that got backlogged.

I guess in order of your points:

1. yeah, in some cases - but we can definitely make this better / more efficient.
2. i agree, because we'd also need termination rights / control actors to be controllable in more fine grained ways
3. i'm not sure how this requires folks to resign contracts - surely they can continue operating with joint ownership of a miner if they'd prefer?
4. only if a lender chooses to agree to terms where they only use the beneficiary address (and no rights for termination?) Afaik no one has done this yet - and would probably be inadvisable to do so.
5. I mean its gotta happen at some point, and as @jennijuju poitns out this was done awhile back

[zixuanzh]

Thanks, I don't have an objection per se; my comment is more on prioritization.