Auto-renew inheritance for contract created tokens

[littletarzan]

Tokens created using a smart contract TokenCreate precompile ask for an Expiry struct with the autoRenewAccount:

    /// Expiry properties of a Hedera token - second, autoRenewAccount, autoRenewPeriod
    struct Expiry {
        // The epoch second at which the token should expire; if an auto-renew account and period are
        // specified, this is coerced to the current epoch second plus the autoRenewPeriod
        int64 second;

        // ID of an account which will be automatically charged to renew the token's expiration, at
        // autoRenewPeriod interval, expressed as a solidity address
        address autoRenewAccount;

        // The interval at which the auto-renew account will be charged to extend the token's expiry
        int64 autoRenewPeriod;
    }

I noticed that contracts I used to be able to deploy are now reverting because the contract deployer cannot use its top-level signature to authorize msg.sender or an account that has signed the ContractCreateTransaction and passed as a constructor parameter as the autoRenewAccount. For now, the only simple way to use TokenCreate precompiles in contracts is to set autoRenewAccount to address(this), which is very limiting. At SaucerSwap, we point all our entities to the same autoRenewAccount for transparency and simplicity across our many contracts. If setting address(this) as autoRenewAccount is the only simple way to create tokens, and address(this) runs out of hbar, then the token eventually risks deletion.

I propose creating an inheritance chain for token auto-renew created using TokenCreate precompile, starting with address(this). If address(this) has no hbar, then Hedera looks at the autoRenewAccount for address(this) and charges that entity. If no hbar is in that entity, then if applicable, charges the contract that created that contract, and so on until no autoRenewAccount is found, then schedule the token for deletion.

Simple example:

Token's autoRenewAccount is a contract --> charge the contract rent --> if no hbar in contract, charge the autoRenewAccount of the contract --> if no hbar in that account, schedule for deletion

More complicated example:

Contract creates a contract with a TokenCreate precompile in the child contract's constructor with address(this)as the autoRenewAccount.

Charge child --> if no hbar, charge parent --> if no hbar charge parent's autoRenewAccount --> if no hbar schedule for deletion

[Nana-EC]

Thanks @littletarzan interesting proposal.

Will circle back for a 2nd review but initial thoughts are that an inheritance of an autoRenew assignment would break the security model since you'd essentially be assigning the autoRenew account to be responsible for rent payments without it's permission.
Accounts (EOAs and contract) should be the only ones able to specify account property changes. Assignment of account roles especially those with fee impacts has to be explicit by the account to avoid tricky undesired impacts.
In Saucers case that's fine as you've explained, however, that doesn't generally scale to all users as some may not want this inheritance.

Notably, I agree on the limiting nature of EVM security model that lead to this. For this reason HIP 755 and HIP 756 were proposed and should address this limited scenario.
Please take a look and let us know your thoughts.
It should address these exact needs but if not it'd be good to hear what's missing.

[littletarzan]

Hello @Nana-EC , my reasoning from the permission POV is if an EOA deploys a contract that creates a token (or other entities), and is setting itself to be the autoRenewAccount, then that EOA is consenting to cover the rent cost the downstream entities created by that contract. To users not wanting this inheritance, my response would be to not set an autoRenewAccount for a token create contract, and keep hbar in the contract's account.

For my use case on a particular contract, we do a TokenCreate in the constructor, but also have function to refund all hbar/whbar inside a contract as a safety mechanism, so we are expecting the contract's hbar balance to always = 0.

[Nana-EC]

Hey @littletarzan,
I think I get it a bit more now.
I may have combined the issue of autoRenew assignment permission with the issue of who pays for a token creation in a contract.
It sounds like the problem here really is "As user I have a process where my contract doesn't always have a balance and therefore can't pay for token renew fee in many cases. In this case can the network check up the entity chain of autoRenew entities to find an entity with enough HBAR to pay. If none fail the transaction"
Is that correct?

If so I'd say the challenges off the top of my head would be

• autoRenew is being used for a related but slightly different purpose than intended. An autoRenew account is intended to pay for a given entities rent renewal, however, it doesn't promise to pay for the hierarchy of entity rent created as a result. To achieve this each new entity should set the desired autoRenew explicitly with the autoRenew account permission. For contracts this is where HIP 755 and 756 are trying to address the limitation.
• there would need to be a limit to the depth of the chain and how far up the network might consider for scalability and perf
• requiring a chain traversal has costs and perf concerns. This would likely require increased gas cost on the token creation operation and potential throttle consideration if not the depth consideration above.

Ultimately, in accordance with the security model only the calling entities balance can be debited for a value transfer/payment. Anything else crosses the boundary as it's not an explicit intent of the entity who's account is being debited

[littletarzan]

It sounds like the problem here really is "As user I have a process where my contract doesn't always have a balance and therefore can't pay for token renew fee in many cases. In this case can the network check up the entity chain of autoRenew entities to find an entity with enough HBAR to pay. If none fail the transaction"
Is that correct?

Yes this is correct

[Nana-EC]

By the way can you share more why in your situation the contract maintains a 0 balance? If HIP 755 and 756 were implemented would transferring enough HBAR at the time of the createToken() provide a solution or is that the solution we're looking to avoid?

[littletarzan]

The contract maintains a 0 balance because it self-custodies swapped whbar and unwraps whbar to itself. The swap router contract 1. performs the swap to whbar, 2. unwraps the whbar to itself, and 3. sends the hbar to user (all done in the same contract call via multicall). Since the router contract is just an intermediary, we do not consider it safe for it to maintain a balance. The contract that creates a token shares the same inheritances as the swap router.

HIP-756 looks like it would work, it addresses the inability for an EOA to be the autoRenewAccount for a token created in a smart contract. I didn't see this HIP so this is good news.

[Nana-EC]

I'd be curious on your initial thought around HIP 756. Would that resolve your issue by allowing you to assign your desired shared autoRenew account to all the tokens and maintain zero balance on your contract creating the token (beyond the fee needed for creation of course)