Start Building
Smart contract rent is coming to Hedera
technical
GEHRIG
Apr 01, 2022
by Gehrig Kunz
Product Marketing at Hedera Hashgraph

🚨🚨Smart contract expiry and auto renewal are currently disabled. Smart contracts will not be charged auto renewal fees or expire.🚨🚨


Since Hedera's whitepaper, the network has focused on building an economically sustainable and increasingly decentralized network. Transaction fees and storage fees have always been a part of this equation.

In the coming months, Hedera will begin charging renewal fees for smart contracts as denoted on our public roadmap. The renewal fee will be defined by the state size the smart contract keeps. 

Smart contract state storage fees, commonly referred to as charging rent, are an oft-discussed topic for layer 1 networks and advocated by Vitalik, Leemon, and others. As part of HIP-16: Entity Auto Renewal and its small update HIP-372: Entity Auto-Renewals and Expiry Window, we’re pushing progress to pioneer smart contract rent.

In this post, we want to help Solidity smart contract developers and the users who interact with them understand how this may impact their design and use of smart contracts.

How does a smart contract pay rent?

There are two ways in which a smart contract on Hedera will be able to pay for its renewal fees.

  1. Self funded. Renewal fees are paid by the hbar held by the smart contract.
  2. [Not yet enabled] External funded. Hbars from a defined Hedera account are able to pay a smart contract's renewal fees.

At the time of this writing, and when renewal fees are first switched on, the second option to use funds directly from a Hedera account will not be enabled. We can however deploy our smart contract to have a payable function, more on this later.

What happens if we don’t pay?

As covered in more detail in HIP-16, your smart contract, consistent with all Hedera entities has a status lifecycle from Active to Removed. This lifecycle looks as follows:

Entity renewal lifecycle
The lifecycle of a Hedera entity

All entities can move through these stages. Once your active smart contract reaches its expirationTime the network will attempt to renew the contract by charging it the renewal fee based on the contract’s set autorenewPeriod. This period, per HIP-372 can be set to a max of 8000001 seconds (~92 days) and a minimum of 2592000 seconds (~30 days).

If this auto-renewal attempt fails, the entity turns to expired status and begins its grace period. This is the period in which an entity, our smart contract in this case is disabled, but not yet removed from the ledger and thus able to still be renewed. Although yet to be determined, Hedera will offer a generous grace period to remove some immediate worry. The example offered in HIP-16 is a 30 day grace period.

Once the grace period expires, the network removes the entity, meaning it is permanently removed from the ledger. To get a more complete view of the proposed implementation read HIP-16.

Designing for the long, immutable haul

Most Solidity developers will aim to deploy an immutable, trustless, and composable smart contract. The code is law, as they say. And this code can often be used by other applications or smart contracts without the worry of it being modified or removed from the network.

Charging rent, or having renewal fees for smart contracts presents itself with important considerations as you both code and interact with smart contracts. Factors to consider may be:

  • How much human intervention is ok to be relied on?
  • Is it acceptable to encourage the community, or perhaps a DAO governing the contracts to fund the contracts via a treasury?
  • Is that trust model strong enough or do we need the contract to be fully self-funding without requiring any outside, responsible parties, at all?

The right answer may ultimately depend on your use case. To help, we put together a few basic economic models to consider with Solidity examples.

Donation-based

The simplest. Rely on the community to dedicate hbar to the smart contract on an ongoing basis. This could be facilitated by the creator of the contract, a community of active users, or a DAO treasury account.

In Hedera's current implementation, it is important to add a function to your Solidity file like the transfer below. This will perhaps be less relevant once an external account can pay renewal fees as mentioned above. 

Code Snippet Background 
// Transfer hbar to the contract without a specified fee

function transfer() public payable {
        // pay the contract
        payMe(msg.value);
 }

Flat, per usage-fee

Your smart contract could implement an additional hbar transfer that is required for each function call. In this scenario, the end-user calling the contract would have to provide a fixed amount of hbars as part of the transaction.  

Code Snippet Background 
// Require a flat hbar fee in return for successful execution

function fixedFunding() public payable {

        require(msg.value == 200000000, “function fee is 2h”);
        // do something here in exchange for the 2h

        // pay the contract
        payMe(msg.value);
    }

The potential dilemma with a per usage model is if the smart contract sees declining or sporadic usage, it may run into times of being short on rent. If demand tapers off, the contract could be forced to transition to being a donation-based or community-supported economic model. For this reason, it may be beneficial to, by default, add a donation function to any contract you deploy.

Dynamic fee
To reward early adopters and better cover any unforeseen future rent costs, it may be beneficial to charge a dynamic amount for use. Perhaps an increasing amount of hbar based upon the contract’s state size or similar.

In this basic example, we keep a count of the number of times we’ve minted a token and have our contract’s associated hbar fee based upon this figure.

Code Snippet Background 
// Dynamically calculate the contract hbar fee

function mint() public payable {
        mintCount = mintCount + 1;
        mintCost = mintCount * 100000000;

        require(msg.value >= mintCost, “fee too low”);

        // pay the contract
        payMe(msg.value);
    }

Further explorations

There is a lot to unpack when it comes to smart contracts renewal fees or rent. As a developer, it’s critical to understand how it may affect your smart contract’s existence on the ledger and therefore usage.

In your early experimental phase a good, safe option may be to have public payable functions for donations and more usage-based fees. As smart contracts become more commonplace on Hedera, and rent becomes a necessity on other networks, it’ll be interesting to see what models emerge.

A few additional challenges and opportunities to consider may be:

With a fixed in USD fee price, how does a smart contract respond to a highly volatile HBAR price? An oracle price feed or our Hedera precompiled contract could offer a way to update the contract based on an exchange rate, for instance.

As staking on Hedera starts to be made available in the coming months, could a smart contract proxy stake its controlled funds, and would that cover its rent? 

As the Hedera ecosystem and broader Solidity smart contract community better explore the ramifications of state storage rent and renewal fees there will no doubt be many more creative economic models. For those starting to deploy the first smart contracts on the Hedera mainnet be mindful of these changes coming and consider the right model for your contract and hopeful community. 

Stay tuned for more details, timing, and fees surrounding a smart contract’s renewal fees, which will be the first of all Hedera entities to eventually pay their fair share. If you have questions join us in discord or contribute enhancements as a HIP. 

View All Posts