> For the complete documentation index, see [llms.txt](https://docs.liquidapps.io/liquidapps-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.liquidapps.io/liquidapps-documentation/dapp-network-services/dapp-network-services/vram.md). # vRAM ### Introduction On EOSIO RAM must be purchased with the chain's system token, we'll take EOS for example. If we check , we can see how much RAM 100 EOS would get me, right now it's 2,875,626 Bytes or almost 3mb. A user based application using blockchain that wishes to cover the RAM costs for users interacting with the platform would under normal circumstances need to acquire enough RAM to cover its users needs now and in the future. The application must also monitor pricing, as we demonstrated above, RAM is a variable cost asset that can change and potentially spike. vRAM enables a developer to reduce the total RAM footprint needed for an application. It does so by taking the need for an application to cover all user to only needing to cover the active users. This limits the amount of RAM needed as well as the exposure to price changes. ### Technical introduction vRAM is a caching solution that enables DAPP Service providers (specialized EOS nodes) to load data to and from RAM <> vRAM on demand. Data is evicted from RAM and stored in vRAM after the transaction has been run. This works similar to the way data is passed to and from regular computer RAM and a hard drive. As with EOS, RAM is used in a computer sometimes because it is a faster storage mechanism, but it is scarce in supply as well. For more information on the technical details of the transaction lifecycle, please read the [vRAM Guide For Experts](https://medium.com/the-liquidapps-blog/vram-guide-for-experts-f809c8f82a27) article and/or the [whitepaper](https://liquidapps.io/DAPP%20Network%20and%20DAPP%20Token%20Whitepaper%20v2.0.pdf). vRAM requires a certain amount of data to be stored in RAM permanently in order for the vRAM system to be trustless. This data is stored in a regular `eosio::multi_index` table with the same name as the `dapp::multi_index` vRam table defined by the smart contract. Each row in the regular `eosio::multi_index` table represents the merkle root of a partition of the sharded data with the root hash being `vector shard_uri` and the partition id being `uint64_t shard`. Note that this is equivalent to having a single merkle root with the second layer of the tree being written to RAM for faster access. The default amount of shards (which is proportional to the maximum amount of permanent RAM required) is 1024 meaning that, the total amount of RAM that a `dapp::multi_index` table will need to permanently use is `1024 * (sizeof(vector shard_uri) + sizeof(uint64_t id))`. In order to access/modify vRam entries certain data may need to be loaded into RAM in order to prove (via the merkle root) that an entry exists in the table. This temporary data (the “cache”) is stored in the `ipfsentry` table. The DAPP Services Provider is responsible for removing this data after the transaction’s lifecycle. If the DSP does not perform this action, the `ipfsentry` table will continue to grow until the account’s RAM supply has been exhausted or the DSP resumes its services. ### Resource consumption in QUOTA Each vRAM action requires 3 `xwarmup` events and 1 `xcommit` event, this can be further leaned out to 1 `xwarmuprow` action, see the [advanced features section](/liquidapps-documentation/dapp-network-services/dapp-network-services/vram/additional-features/advanced-features.md). Each action is charged in QUOTA, the default for a package is `0.0001` QUOTA per action unless the DSP increases that default amount which they may do at any time. ### vRAM in the context of user-based applications vRAM requires a short period of time for when the DSP loads the required data from IPFS and pushes it into RAM so that the user may use it. The vRAM multi index table has a field for delaying the cleanup action for the associated data, `delay_sec`. The current `delay_sec` logic operates on deferred transactions which are deprecated; however, the **LiquidScheduler's** schedule service would be a great use to schedule the committing of the user's data for the future. If this delayed cleanup is set to say an hour and an action `load` is called at the user's login. The DSP can load all of the associated data for that user until that user becomes inactive. The delay period can be pushed back each time the user performs an action thus creating a cache-like system. The timer can be cancelled and a new timer created for this logic. This allows the developer to reduce their total RAM footprint while also not compromising transaction speed. ### PostgreSQL Alternative Storage Option IPFS is still in beta, thus the DAPP Network has implemented an alternative storage solution using PostgreSQL which is scalable, reliable, and easier for devops types to use. Data is also stored in IPFS to allow for peering, but DSPs can be configured to also add/fetch from PostgreSQL.