Hedera Technical Insights: Rent on Hedera | Hedera Hedera Network Services Token Service Mint and configure tokens and accounts. Consensus Service Verifiable timestamps and ordering of events. Smart Contracts Run Solidity smart contracts. HBAR The Hedera network's native cryptocurrency. Insights How It Works Learn about Hedera from end to end. Explorers View live and historical data on Hedera. Dashboards Analyze network activity and metrics. Network Nodes Understand networks and node types. Devs Start Building Get Started Learn core concepts and build the future. Documentation Review the API and build using your favorite language. Developer Resources Integrations Plugins and microservices for Hedera. Fee Estimator Understand and estimate transaction costs. Open Source Hedera is committed to open, transparent code. Learning Center Learn about web3 and blockchain technologies. Grants Grants & accelerators for your project. Bounties Find bugs. Submit a report. Earn rewards. Ecosystem ECOSYSTEM Hedera Ecosystem Applications, developer tools, network explorers, and more. NFT Ecosystem Metrics Analyze on-chain and market NFT ecosystem metrics. CATEGORIES Web3 Applications Connect into the innovative startups decentralizing the web on Hedera. Enterprise Applications Learn about the Fortune 500 companies decentralizing the web on Hedera. Wallets & Custodians Create a Hedera account to manage HBAR, fungible tokens, and NFTs. Network Explorers Hedera mainnet and testnet graphical network explorers. Developer Tooling Third-party APIs, integrations, and plugins to build apps on Hedera. Grants & Accelerators Boost your project with support from the Hedera ecosystem. Partner Program Explore our partners to bring your vision into reality. Hedera Council Over 30 highly diversified organizations govern Hedera. Use Cases Hedera Solutions Asset Tokenization Studio Open source toolkit for tokenizing assets securely. Stablecoin Studio All-in-one toolkit for stablecoin solutions. Hedera Guardian Auditable carbon markets and traceability. Functional Use Cases Data Integrity & AI Reliable, secure, and ethically governed insights. Sustainability Enabling fair carbon markets with trust. Real-World Asset Tokenization Seamless tokenization of real-world assets and digital at scale. Consumer Engagement & Loyalty Mint, distribute, and redeem loyalty rewards. Decentralized Identity Maintain the lifecycle of credentials. Decentralized Logs Scalable, real-time timestamped events. DeFi Dapps built for the next-generation of finance. NFTs Low, fixed fees. Immutable royalties. Payments Scalable, real-time, and affordable crypto-payments. HBAR Overview Learn about Hedera's token, HBAR. Treasury Management Hedera’s report of the HBAR supply. Governance Decentralized Governance Hedera Council See the world's leading organizations that own Hedera. About Meet Hedera's Board of Directors and team. Journey Watch Hedera's journey to build an empowered digital future for all. Transparent Governance Public Policy Hedera's mission is to inform policy and regulation that impact the industry. Meeting Minutes Immutably recorded on Hedera. Roadmap Follow Hedera's roadmap in its journey to build the future. Resources Company What's New Partners Papers Careers Media Blog Technical Press Podcast Community Events Meetups Store Brand Navigation QUICKSTART Hedera Technical Insights: Rent on Hedera technical Jun 14, 2019 by Paul Madsen Head of Identity, The HBAR Foundation We are used to paying based on how long we use some resource – whether parking meters, toll highways, or safe deposit boxes. We don’t purchase the above in order to give ourselves indefinite rights, but rather rent them – paying an amount per unit of time. The DLT industry is recognizing the need for the same model in charging for usage of the resources of the network – moving from ‘ownership’ (in which a client could effectively buy a piece of the shared ledger of transactions and state in perpetuity with only a one time ‘purchase’) to ‘rent’ (in which clients are expected to continuously pay for the network maintaining and storing a given piece of data). Hedera has designed rent into the fee structure – clients pay for storage based on how large a data object is and how long it is to be stored. What is rent? Rent, in the context of DLTs, refers to a requirement that clients storing objects in the consensus state pay a fee for that storage and that the fee will reflect the temporal duration of that storage. If the initial transaction that creates an object does not have the requisite rent, the creation will fail. Likewise, once an object’s rent fee has run out, it can be removed from state. Different rent models can be distinguished by: How is rent paid? For instance, does rent manifest as explicit fees collected from the client? Or are coins instead burnt (and so contribute to deflation)? Which party receives the rent? For instance, does it go direct to the nodes storing state? Or is it collected on behalf of those nodes? What happens when rent runs out? For instance, is there a period of reduced access or functionality to alert the owner of the imminent deletion? Once deleted, is recovery possible? If there is a recovery mechanism, from where is the ‘backup’ retrieved? Immutability? How do we reconcile rent and the potential for the deletion of some data from the ledger with immutability? A DLT’s fundamental purpose is to allow a network of nodes to establish a consensus state of some set of business data, e.g. how many coins each party has, where in the world various shipping containers are located, etc. This would be trivial were it not for the fact that transactions are constantly changing the state, e.g. coins are being spent, shipping containers are being shipped, etc. The state is by definition mutable – it changes constantly based on the transactions that are occurring. Immutability of state then means not that changes can’t occur, but rather that only valid changes can occur – where validity is defined by the network. The default policy for changes on blockchains has been: Accounts can be created Account state can change, if the transaction is signed by the appropriate parties Smart contracts can be created, but not subsequently modified or deleted Smart contract state can change, if the transaction is signed by the appropriate parties The possibility of deletion, should an object’s rent run out, extends the above list to include: Accounts and smart contracts can be deleted, if their rent runs out Note: some proposals for rent do not require an automatic deletion mechanism. Instead, clients effectively pay for the present value of an infinite sequence of storage costs, for all time, and are encouraged to remove data from state when it is no longer relevant with a refund of some of the initial fee. Why is rent necessary? The consensus state is maintained by all network nodes – if state is allowed to grow without bounds, then the storage burden associated with running a node would grow accordingly – and likely preclude smaller actors with less financial resources from acting as nodes. Rent is designed to: Discourage dishonest clients from performing a denial of service attack by uploading large volumes of data to the ledger – forcing nodes to store those terabytes and potentially filling up storage – and so preventing valid transactions from being processed. Rent does not prevent the attack, but can make it economically prohibitive as the attacker necessarily needs to pay for the storage of those bytes for as long as they run the attack Encourage honest clients to be discriminating in creating and storing objects in state. Without rent, honest nodes might not fully confront the negative consequences of indiscriminate storage and sloppy smart contract programming, causing the same state growth as in the above attack even if unintentional Additionally, rent can help to encourage parties to run nodes, because rent can be used to compensate (either directly or indirectly) nodes for the costs associated with storing state. Rent & smart contracts It is for smart contracts that the possibility of deletion due to rent depletion is arguably most significant – this is because: Smart contracts may be large – both bytecode and their own internal state – and so amplify the need for rent Multiple parties may have a vested and differing interest in the continued persistence of a smart contract Consider a dapp that uploads an ERC20 smart contract and pays rent for the first year of storage of the bytecode and the initially small internal state. Over that year, the token grows in popularity and so the size of the internal state tracking ownership of that token grows accordingly – possibly growing well beyond the size of the bytecode. It may be the user who pays for each individual increment in the size of the state. After a year, the contract’s rent is up for renewal – who should pay the rent for the now much larger combination of bytecode and internal state? Should it be the contract owner (if one exists)? Or the users? Or both? The issue is represented in the graphic below: If the smart contract owner designed a suitable economic model for realizing profit from the token’s popularity, then they would hopefully have both the motivation and the means to fund the next year of storage. But perhaps the dapp was designed to not have an owner, and to run independently for the benefit of its users. The individual owners of the tokens clearly do not want the smart contract to disappear, taking with it all their value. Given that interest, shouldn't they contribute to the costs of the persistence of that value? Of course, if neither the owner nor users are motivated to contribute to the rent of a smart contract, then it’s questionable whether or not it has any value and even needs to be continued to be persisted in state. Below are potential models whereby the risk of deletion from unanticipated future state size growth can be mitigated: The smart contract owner takes on the responsibility of paying rent, but designs in constraints to the size of state to control its future rent costs. For instance, imagine a contract for some tokenized real estate that restricts the number of part owners at 100 – potentially enhancing value through exclusivity The smart contract owner takes on the responsibility of paying rent and designs a revenue model that ensures they will always have sufficient funds to cover rent and prevent deletion The smart contract itself collects tiny fees from its users every time they interact with the contract and so effectively self-funds its future rent. As long as the contract has sufficient usage, it can continue to cover its rent Hedera's rent model Hedera’s fee model ensures that the storage of any object reflects: The size of the object in bytes The duration of the storage in seconds The relative scarcity of the storage medium, such as RAM v. hard drive When a client creates an object (account, file, or a smart contract) in state, they submit a transaction that specifies an expirationTime as the time in the future that the object will no longer be needed, and can be deleted. The total fee for that transaction will include the normal fees of submitting a transaction and having it processed. In addition, it will include the fee for the number of bytes that are being stored, multiplied by how long they will be stored. There will be a price in hbars (bytes * time) for storing it in RAM, or a lower price for storing it on the hard drive (or other storage device). Typically, accounts are in RAM, and files and smart contract states are in storage. The rent is collected by the Hedera Treasury. Once a day, the nodes that are storing the data receive a payment from the Treasury that is designed to compensate for the associated costs (for all storage, not each object individually). The two are not tied to each other, so in the short term, Treasury can make up for insufficient rent being charged. In the long term, the economics should average out so that the nodes are compensated enough to cover the storage costs, and the rents are sufficient to cover the amount that Treasury is paying. This initial fee pays for the storage of the object until the expirationTime. After that time, unless the rent has been extended, the object will be automatically deleted from the state by all nodes. To prevent this deletion, one way to extend an object’s rent is with an explicit update transaction. For instance, if a file was initially created with an expirationTime one year in the future, after 11 months the client could ensure the continued persistence of the file for another period of time by sending a fileUpdate transaction giving a new expirationTime (necessarily later than the first). The rent fee for this storage extension would be determined by subtracting the old expirationTime from the new. For crypto accounts and smart contracts, there is an alternative option for paying rent – the client can stipulate an autoRenewalPeriod – after which time the rent for that account or contract will be automatically paid. For instance, if the transaction creating a smart contract stipulated an autoRenewalPeriod of 3 months, then the client’s account would pay for the initial 3 months of storage (for bytecode and initial state) and after that time period of time, the smart contract’s associated crypto account would pay for 3 more months of storage (of both bytecode and the new state). As long as the associated account had sufficient hbars, the contract would live indefinitely – paying for itself 4 times a year without the need for explicit update transactions to be sent. Auto renewal is not an option for files as there is no associated crypto account from which those rent fees could be withdrawn. The third model for paying rent for smart contracts discussed above, specifically requiring that users make payments into the smart contract’s associated account so that the contract will be able to pay the next rent fee, is directly supported in Hedera. This model is shown below; each smart contract call sent by a user would effectively pay for its own current rent for any growth in state (sent to Treasury as described above), as well as future rent (sent to the smart contract’s account). Summary: We have designed the economics of Hedera such that transaction fees account for the: Degree to which a given transaction consumes the resources of the network The scarcity of those resources The duration for which the resources are consumed Rent for storing crypto accounts, smart contracts, and files in the consensus state maintained by all nodes is a natural consequence of the above model. Share This Back to blog What is gRPC, gRPC-Web, and Proxies? Ed Marquez Pragmatic Blockchain Design Patterns – Integrating Blockchain into Business Processes Michiel Mulders Zero Cost EthereumTransaction on Success: Hedera's New Fee Model for Relay Operators Oliver Thorn Hedera Adopts Chainlink Standard for Cross-Chain Interoperability To Accelerate Ecosystem Adoption Hedera Team Hedera Developer Highlights March 2025 Michiel Mulders Hedera Release Cycle Overview Ed Marquez View All Posts Sign up for the newsletter CONNECT WITH US Transparency Open Source Audits & Standards Sustainability Commitment Carbon Offsets Governance Hedera Council Public Policy Treasury Management Meeting Minutes LLC Agreement Node Requirements Community Events Meetups HBAR Telegram Developer Discord Twitter Community Support FAQ Network Status Developer Discord StackOverflow Brand Brand Guidelines Built on Hedera Logo Hedera Store About Team Partners Journey Roadmap Careers Contact General Inquiry Public Relations © 2018-2025 Hedera Hashgraph, LLC. All trademarks and company names are the property of their respective owners. All rights in the Deutsche Telekom mark are protected by Deutsche Telekom AG. All rights reserved. Hedera uses the third party marks with permission. Terms of Use  |  Privacy Policy