HIP-16: Entity Auto-renewal

[kenthejr]

This discussion is designated as the discussions-to target of hip-16. Use this thread to further develop the HIP and move it through to its final lifecycle state.

[coltsfanatic07]

The overall theme is solid. I would like to see the actual workflow between the phases laid out a little better between expiration > deletion > removal. Looks like a loophole if an account has any type of token balance. Obviously said account would not be able to operate on the network but would still have the contents of the tokens in the account. Not sure if even the renewal process would work say 9 months later or if the account would be hopelessly locked out of the network expired.

[kenthejr]

@lbaird @noshmody ^

[lbaird]

A "delete" transaction marks the account as deleted, and transfers all its tokens to their treasuries. The account remaines "deleted" until it expires, at which point it is removed. It can't be renewed while it is deleted.

When an active account reaches its expiration time, it tries to autorenew. If it has a large enough balance, it autorenews according to its autorenew period. If it has a smaller balance, then it autorenews for as long as it can afford. If it has zero balance, it expires. It remains expired during a grace period. Anyone can renew it during the grace period. Everything about it is frozen (including tokens) until it is renewed or the grace period ends. At the end of the grace period, if it still hasn't been renewed, then it is removed and the tokens in it are transferred to their treasury accounts.

The grace period will most likely be a week. Not 9 months. It is frozen during that week, but can be unfrozen at any time by someone paying to renew it. Anyone can do that.

[bugbytesinc]

How about a 30 day grace period? Seems a week might be a bit short for a corporate entity if it had a hiccup in their organization (granted the "anyone can renew" part might be an argument against that).

[lbaird]

I think 30 days would be fine.

[raybeecham]

I would say 15 days would be okay, but 30 days doesn't seem bad either.

[JaimeSilver]

Ken,

I reviewed the proposal and there is one black spot for the authorization/signing for the "autorenewal account". In my mind, the process of scheduling any withdrawal needs explicit authorization from the account being debited. Instead of submitting the transaction, the background process should build the transaction and schedule for signing (one or many).
The biggest challenge is perception: the nodes could set the state of an object and fix the "autorenewal account", and without previous consent withdraw funds to keep the base object alive. The same pattern to modify a large transfer that shifts the staking position of a node, so instead of processing background renewal fees, but then opens the window to withdraw larger balances.

By the way, the same mechanism could be used to orchestrate transactions via scripts that match the HAPI definitions; I imagine files that have the variables to be populated by a background demon (I imagine a JSON file that creates the transaction of the scheduler).
If needed, one could delegate authorization to a signature hosted by a "mirror node" to sign transactions on one's behalf.

[lbaird]

When an account is attached to an entity as an autorenew account, the owner of that account must sign the transaction that attached it. That would be either a create transaction or an update transaction for that entity. That signature is an authorization for that account to pay for autorenewals for that entity.

A mainnet node can't arbitrarily decide to change the fields of an entity, such as changing its autorenew account without the owner's signature. That would be as bad as arbitrarily increasing the balance of hbars in the account for no reason. Either kind of malicious behavior causes that node's state to differ from all the honest nodes, so the other nodes and the mirror nodes will ignore it. A state is never believed unless many nodes all sign it. So a lone malicious node can't break the rules.

[JaimeSilver]

I am okay with this solution for the autorenew account.
My only suggestion then will be to make the autorenew field populated (explicit), so we can query directly the accounts that will be debited by each object.

[lbaird]

All fields are explicit. You can read them with a getInfo query. And update them with an update transaction. An auto-renew will use hbars from the auto-renew account, if it exists, and if it contains enough hbars. Otherwise, hbars within the entity itself will be used (if it's an account or smart contract).

[JaimeSilver]

Thank you, Leemon.

[JaimeSilver]

There is a second request and is the inheritance of payer accounts for objects. Will the original paying account be the one selected to pay for autorenewal? There is a scenario in which a Smart Contract creates other contracts (known as a factory contract), and yet it should be tagged to the same autorenewal account. Files should be the same.
Last, paying account should be explicit to facilitate standard querying to find the account is paying for which state objects.

[lbaird]

The intent is for most entities (e.g., files or topics) to have a field that specifies the autorenew account. That field is set when it is created, and can be changed when it is updated. Any create or update that attaches an account to it must be signed by the owner of the account being attached.

The original idea was that neither accounts nor smart contracts would need that field, since they already have the ability to hold hbars useful for autorenewal. But I think it would be useful to add it to them, too. That makes the system more orthogonal: every entity has an optional autorenew account attached to it. It would also be useful for the scenario you describe for smart contracts. And it would be useful for a case such as a company creating many accounts for their customers, and then wanting to be able to pay the autorenew fees for the customers so the customers don't have to worry about it. In that case, the company could have a single account for autorenewing, and attach it to every customer account. Then the customers won't have to worry about their account disappearing, even if they have zero balances for long periods.

[JaimeSilver]

I agree with this approach. For security reasons we may have contracts that are intented to not carry hbars.

[rhysied]

I noticed that the HIP mentions accounts that cannot pay for the max auto-renewal period will have their whole balance used to partially increase their auto-renewal duration, however there is a minimum of ~81 days.

Assuming that entity does not have enough funds to pay for the minimum renewal duration, does it get an "upgrade" to the minimum or is there a grey area where non-zero balance accounts may expire with funds available?

aside from that it all seems good to me

[kenthejr]

There should not be a min or max on autorenew times. If it can autorenew for the number of seconds that entity specifies for its autorenew period, then it does so. If it only has the funds to autorenew for a shorter period, then it uses all its funds, and autorenew for as long as it can. Even if that’s only for 1 second.

The min and max is only for when you’re creating or updating an entity, and you choose the autorenew period. That’s the only time we look at the min and max. Not during the handling of the actual auto renewal itself.

[bugbytesinc]

What about special accounts? Like the treasury of a token or the autorenew account for an immutable contract?

[lbaird]

Any update that extends the expiration date of a TokenType or adds/changes its treasury account will also update the expiration of the treasury account as necessary to ensure it expires at the same time or later than the TokenType.

The same should be true for the autorenew account for any entity that cannot be updated (because it has no admin key).

The above is what was intended. But maybe we should extend it to all entities. That would make the system more orthogonal and cleaner. And there may be cases where it would be very inconvenient for an auto-renew account to expire and be removed, and then have to go update all the entities that were using it.

So it's probably better to simply say that any time an entity is updated to extend its life, the life of the auto-renew account should also be extended to at least that time (if it isn't already that long or longer).

[kenthejr]

FINAL CALL FOR COMMENT

This HIP is scheduled for progression to Final status if no other contributions are made by the community. If no issues are raised or pull requests made within the next 7 days, this HIP will be updated to Final status and this discussion thread will be closed.

[kenthejr]

Hedera Council Technical Committee has ratified this HIP

Once the FINAL CALL FOR COMMENT period has expired and no additional concerns have been raised, this HIP will move to its final state based on its type.

[cylon56]

Motivation: For a public ledger to avoid suffering a tragedy of the commons it is important that all participants in the ledger share in the cost of ledger resources used. Renewal and auto-renewal fees are the implementation of this principal.

I agree with this sentiment. If certain companies or users are overusing storage entities, they should pay more rather than spread that cost to more efficient users. However, if the motivation of HIP-16 is to prevent a tragedy of the commons, shouldn't it also be simultaneously accompanied by a reduction in transaction fees for other services?

I'm curious to know the exact costs for storing entities vs. transaction processing. If all users up till now have been paying extra fees on transactions as a result of entity storage, it would make sense to remove those extra costs as soon as HIP-16 is implemented. This would also ensure that any apps that rely heavily on entity storage for their use-cases will get some savings elsewhere to lessen the impact.

I recommend expanding on the cost savings for users and the impact it will have on improving the affordability of the platform. This will provide justification for what might otherwise be considered an additional fee. I'm sure that the exact fee amounts won't be fully known until the final implementation but there are still ways to ensure that prices on other services are proportionally lowered. I would request that HIP-16 include a commitment for transaction fees to be lowered by a certain ratio relative to rental fees added before the community moves to finalize it.

I see no issues with the technical implementation laid out. Rental fees for state storage economically make sense and this seems like a good way to do it. We should just be sure that HIP-16 benefits Hedera users as much as node operators by shifting the cost savings accordingly. Without that assurance, I don't see the primary motivation being addressed here as node operators could still charge the same fees in addition to rental storage, leaving users paying more in the end, not less.

[kenthejr]

@lbaird might be able to provide more context, but it's my understanding that storage fees have been set at 2160 hours (3 months) for all transactions that require storage (files, accounts, tokens, topics, etc). The renewal mechanism was just pending implementation so the decisions was made not to expire entities until that mechanism was implemented.

To be clear, there were no "extra fees" to cover the storage cost previously. Those transactions that resulted in storage were charged for 2160 hours of storage and those that did not require storage were not charged for storage. The pricing schedule would not change because of this HIP. The pricing schedule was designed originally in the context of having auto-renewal and expirations.

[cylon56]

That makes sense. The "extra fees" I'm referring to are not explicit but rather implicit in the sense that I would assume Hedera nodes would need to charge more overall to cover the operational costs for entity storage. However, I wasn't fully aware that these fees are already in place so it sounds like this HIP-16 would only change the fact that expiration is now enforced.

That being said, I would appreciate a more detailed explanation of how current fees are determined for transactions and entity renewal relative to the real costs of operating a mainnet node. In other ecosystems such as Ethereum, real market forces determine transaction fee costs, and node access is open and easy to benchmark costs for. Hedera's fee model is comparably cheaper and more stable, but it's less transparent in how prices are actually set. I understand a Pricing Committee mostly handles that under the Hedera Council, but the criteria they use becomes relevant when discussing HIPs such as these that will impact fee structure.

My main concern is to avoid fee increases that could negatively impact certain Hedera use-cases as some applications could be rendered economically infeasible by fee structure changes. Given @kenthejr's comment, this doesn't seem to be the case for HIP-16, but other fee increases earlier this year came as an unpleasant surprise to one of my clients that led them to discontinue development efforts on Hedera.

If anyone could provide more detail on the Pricing Committee's criteria for setting fee prices, that would greatly alleviate my concerns.

[emptypockts]

Hi I think account deletion is not a good idea for any customer that suddenly sees their account gone. I think a better customer experience is to freeze the account until fees are paid to remove the freeze but not delete.

[0x-esh]

Going through some Hedera SDK examples over the weekend, I stumbled upon the output of one call mentioning the account expiration in 3 months. Naturally it seemed odd to me and earlier today we had this discussion on Discord, when I tried to understand better the logic behind this and most importantly, why this is handled in such way.

I must say that I do understand the goal of keeping the ledger compact, and getting rid of the empty and inactive accounts. However, it looks like as if it was discussed among the developers only, without taking into account any end-user experience, business considerations or even legal aspects of how this works.

Let's have a look at the example, keeping in mind that you have some end-users yet to create wallets (for which the news about this might be less surprising) and you have the users already with the wallets (who would not be aware of this and would be extremely surprised by the outcome of the change). Neither group is aware of the fact that the account has a 3-months recurring subscription (which has not been charged for just yet). Now let's take probably the most popular subject of NFTs or any other "native tokens" you might want to issue or want to have issued to you and look at it from the perspective of the "buyer" and the "seller" (where the seller in this case is the issuer of the tokens acting as a business).

The seller/issuer issues custom tokens and transfers them to the "buyer" (we would also call the user the "buyer" if the tokens were transferred at no cost as a gift for example). The "buyer" is happy with the "purchase" (notice that most NFT markets, including the companies using Hedera to issue NFTs are using the term "sale", rather than say "lease", when offering their services to the customers).

Imagine that your seller is entity A, and the person receiving the tokens is entity B. Now also imagine that the "feature" of account expiration comes into force and the account of B has no HBAR funds - just the tokens. 3 months later + the grace period you have these scenarios playing out:

a) User B (and other users like it) finds that the account is gone, and the assets paid for are effectively "re-posessed" by A, breaching the terms of sale.

b) Entity A finds itself in the hot water with a string of complaints - such as formal (say to ICO), or informal (such as posting that "entity A stole the items which were paid for" on multiple forums, etc), resulting in monetary and reputational damage.

Now don't get me wrong - as I said, I understand why there is an attempt to get rid of the empty and inactive accounts, but the way it is being done is far from perfect and, if progressed to being activated like this, will drive quite a few end users away once it is widely known. Also keep in mind that the attention span of the regular users will result in multiple wallets being forgotten about for a while and when they remember they had a wallet and the assets, there will be dissatisfaction and complaints. This will be even worse for those already having wallets and already having some assets transferred or purchased - those will just disappear if there are no HBARs available there for "renewal", without any "heads up" about it.

Also don't forget about the headache for the issuer/seller too - if it was the issuer that "sold" an item/asset, and that item suddenly gets transferred back, there would have to be a process to track that and refund the customer. And if that was a "secondary" sale, then that secondary seller will have complaints against, which is not nice either and would potentially kill the secondary market of the assets.

Having said that - is there an alternative? Possibly. For starters, don't make this effectively a "hidden" fee/change (which could be a bad surprise for all parties of the deal, and might have legal consequences too). For example, make it an obvious requirement to have a "reserve" (sufficient to cover the recurring sub for years ahead) that cannot be spent or transferred out and that is required to "fuel" the account and its renewals (perhaps similar to the XRP reserve). This would also make the "transition" easier potentially, so you do not "surprise" those already having a wallet and assets with their mysterious disappearance, but say just prevent any further operations with the existing wallets until the reserve is there. In any case, this is something I believe that is worth discussing, as was suggested in Discord channel.

P.S. Please note that even the reserve approach might be not so great for the end-users, because in a way it still takes away the "sense of ownership" - even though you "bought" those NFTs for example, you still have to pay for the account to keep them in, because those tokens are not something you can transfer out of the network (well, maybe later with some bridges and such, but again - not for the "regular" users). But at least it does not give you this feel of "I don't own those digital assets at all, I'm forced to pay for them still every 3 months so they don't disappear".

[nkavian]

This feature is very difficult to swallow. Perhaps I could share my use case..

We manage multi-sig wallets on-behalf of financial institutions. We provide the technical platform that the wallet works on and we perform all the engineering work. While the institution is non-technical, they simply manage their balances on the wallet.

Trying to explain to them the following points just won't fly:

1. maintain a minimum HBAR balance or your account will be closed,
2. and if your account goes offline, your institution can't transact,
3. and if your account goes offline, your stable coins will also be "refunded" back to the stable coin owner's treasury,
4. and if our platform can't pay the autorenew fees on your behalf, your account can still be closed,

On our side, we could try to mitigate some of those issues by:

• deposit 1 HBAR into each new account we create,
• prevent the institution from withdrawing that last 1 HBAR (now on every transaction I have to getBalance first),
• create a daemon process to check account expirations and allow our operator account to top up.

But this just shifts the pain yet again.

• if someone mistakenly creates a million accounts and we deposit 1 HBAR each, then let's say after 50K creations our operator wallet is drained, then we're back to square one again, denial of service.
• in order to have our operator account pay for the "manual" auto renewals, we have to call once a day CryptoGetInfo to check if we are within the last 7 days, and then pay the renewal. Unfortunately, CryptoGetInfo is not free.
• also being explicit, it takes resources to build the tools and then ongoing effort to perform monitoring.

Additional pain:

• The HIP and other discussions are vague about multi-sig. I don't believe I've seen a clear explanation of the impact on multi-sig wallets. If 1 of the signer's accounts expire, is their private key still valid to sign transactions?

These financial institutions will likely eject on Hedera if we are transparent about these risks, they will choose one of our existing chains.

A few feedback items:

• make CryptoGetInfo free.
• allow setting the operator (during account creation) as the admin/owning account that will pay all future renewal fees (true auto renewal!!, not this current manual renewal which isn't "auto" CryptoAccountAutoRenew).
• if an account is holding a stable coin valued above a certain threshold like $1, do not under any circumstance close the account. Transaction fees are pegged to the dollar, repurpose the same code to analyze the stable coin value held. i.e. guarantee custody of the stable coins do not revert to the treasury.

[Gomez33]

Update