Abstract HotPocket smart contracts are spun up through 3rd party hosts, tenants (smart contract deployers) must acquire lease NFTs from hosts to spin up their smart contracts. Hosts would be offering their hosting services on Evernode through lease NFTs which represents an instance on their respective servers that provides computation, consensus participation and disk space for contract state. High level overview Smart contracts are spun up in this flow: 1. Tenant purchase lease NFT from host on the XRPL DEX 2. Host provisions an instance for the tenant's smart contract 3. Host sends the instance's details to the tenant 4. Tenant sends the contract's bytecode & its files to the host 5. Host conducts consensus for state transfer and synchronization 6. Hosts configures the contract based on the state and goes autonomous In-depth details How tenants acquire lease NFTs If a tenant finds a host fit for its smart contract, the tenant would first verify the host's registration on Evernode through its ownership of a Registration NFT issued by the Evernode Hook, the tenant would then proceed to purchase one of the host's lease NFT listed on the XRPL DEX for a set amount of price determined by the host early on. Example transaction, lease NFT bought by the tenant: Buy_Offer Tx here Once the lease NFT has been acquired, the host's message board service (mb-xrpl) would be picking this up and start provisioning an instance for the lease and increase its occupied instance count on the Evernode Hook by 1: Tx here (Check Memos field) Internal logs: For the curious ones: Container 00010000... is the instance, all instances are Docker containers How bytecode is transferred from tenant to instance After the lease NFT has been purchased and the instance has been provisioned on the host, the host would send the instance's details to the tenant through an XRPL transaction's Memos field, the details include the instance's user_port, instance size and other details. The tenant must connect to the instance's user port (22600+instance #) via websocket and transfer the contract's bytecode and its contents (files & configuration) to bootstrap the contract. Example transaction, sent from host to tenant, the contents are encrypted using the tenant's Message key: Tx here (Check Memos field) After the contract's bytecode and files are stored on the instance, the instance's HotPocket service would connect to its designated peers (referring to the default set UNL during initial configuration) and conduct consensus with other nodes for a state transfer and state synchronization. How tenants extend their leases A lease has to be extended by its tenant for the host to continue providing its hosting services to the smart contract. A lease is extended by a tenant sending additional EVR to the host's XRPL account with the lease NFT on the tenant's XRPL account: Tx here A lease is successfully extended when additional EVR payment is made and the host confirms the lease's extension by sending a transaction to the tenant: Tx here (Check Memos field) Internal logs: If a tenant were to fail at extending their lease, the instance's expiry date would be reached and the lease would be terminated, resulting in the instance's deletion and the lease NFT's burn. In order for the tenant to spin up their contract on the same host again, they must repurchase the host's lease NFT and start the whole process all over again. Credits Author - @wojake Please note that this material was written independently, the research done and its contents might be invalid or outdated as time progresses, please DYOR. Welcoming all views, discussions, thoughts and questions on this thread.

Abstract HotPocket smart contracts hosted on Evernode are layer-2, thus making them function and interactable on 2 different networks. HotPocket smart contracts operate on their own respective cluster of 3rd party hosts (nodes), or to simplify: their own independent L2 network built atop of the XRPL. HP smart contracts are therefore interactable on their respective L2 network via websocket as well as on the XRPL via their own XRPL account. There are 2 primary ways to interact with HP smart contracts: The XRPL (L1): Primarily value-based transactions (deposits & withdrawals) and encoded messages/instructions via the Memos field. The contract's cluster (L2): Interactions between the cluster's nodes via websocket, allowing you (as a user) to call functions, compute and key-in data on the smart contract. The smart contracts' code, state and execution of their code are not performed or stored within the XRPL whatsoever but HP smart contracts are interactable on the XRPL as each smart contract would have its own XRPL account controlled by nodes in a decentralized manner using a multisig solution which allows selected nodes to systematically come to agreement on on-chain transactions, making HP contracts truly decentralized on both layers (L1 & L2). XRPL's multisig solution The XRPL has a multsig solution which allows your account to define a list of trusted accounts, which gives them the right to sign transactions on behalf of your account. This feature enables nodes to control a contract's XRPL account in a decentralized manner. A little fact on XRPL's multisig: An XRPL account that has setup multisig features a list of accounts with their own respective voting power/weight and a minimum required quorum value, which if reached, will allow a transaction to be validated successfully on the XRPL. Example: How nodes participate (w/ multisig) Let's make an example environment where a contract has 13 nodes on its cluster: The contract could only have 8 out of the 13 nodes to be included on its XRPL account's multisig list, 5 other nodes will not be having on-chain voting rights on the contract's XRPL account as there could only be 8 signers on a multisig list (unless the ExpandedSignerList amendment passes, which would allow 32 signers to be on a multisig list). If the ExpandedSignerList amendment is enabled in the future, contracts could be much more decentralized and trustless as the custody to their XRPL account would be shared among up to 32 nodes. This would also have the benefit of making it much more difficult to compromise the contract's XRPL account through insecure nodes. If you're a rippled validator and want to see Evernode succeed, vote Yes for the ExpandedSignerList amendment: it helps Evernode as a platform as smart contracts hosted on 3rd party hosts are able to distribute on-chain voting permission to 32 nodes compared to 8 which increases security and the decentralized aspect of contracts. Welcoming all discussions, thoughts and questions on this thread. Credits Author - @wojake Reviewer - @efFofexX

With the Evernode Foundation announcing the start of their public beta test phase, they're inviting every interested individual to participate in the beta test and run a server on their test platform, with zero additional cost to participate. The Foundation's official announcement: https://twitter.com/EvernodeXRPL/status/1540901839570620417 Each participant must have their own server and a registered GitHub account to be apart of the beta test, the GitHub account will be used to join the Foundation's private repository which contains the installation link and the necessary info/updates on the public beta test phase. Participants will send out their GitHub username to the team (via Twitter) and the team will then invite you to their private repository via GitHub entirely. No participation fee is needed, test EVRs will be provided via their test faucet to register on their test platform (test EVRs have no absolute value!). Best of luck to everyone. Here we are, reaching a small yet important milestone for the project. The Foundation's twitter account: https://twitter.com/evernodexrpl The Foundation's GitHub organization: https://github.com/HotPocketDev The Foundation's Website: https://evernode.wordpress.com/

Evernode incentivizes host setup by issuing and distributing $EVR to participating and reliable hosts at a fixed rate. The reward rate for eligible hosts at the time of Evernode's public launch on the mainnet (Epoch 4) will begin at 64 Evers per Moment (~6 minutes), and the reward rate will halve every epoch in order to benefit early adopters. The reward distribution scheme is structured to favor early adopters as it will help bootstrap Evernode with reliable host operators since each new host is relatively more valuable to the network when the network is young and small. It is crucial to have reliable participating nodes at the platform's inception so that smart contract developers can have a broad choice of nodes for smart contract deployment. Auditors will regularly perform QoS audits to verify whether an Evernode Host is sufficient enough to earn hosting rewards. Newly minted $EVR will be shared equally between all participating and reliable hosts. Evernode discourages "token farmers" (unreliable nodes that just want the hosting rewards) by not rewarding them at all. Smart contract developers will most likely not choose a suspected "token farming" host based on its service's resources and history. We discourage any token farming behavior as it provides no value to the platform.

Evernode Evernode is a layer 2 smart contract solution composed from the XRP Ledger. Evernode is a smart contract hosting platform consisting of off-chain nodes that directly run pieces of code, consensus and maintain a distributed, canonical state to provide flexible layer 2 smart contracts to the XRP Ledger. Introduction To achieve layer 2 smart contracts, Evernode combines multiple technologies together to form an off-chain solution that runs in parallel with the XRP Ledger. By operating as an off-chain solution, Evernode is able to have its own platform of nodes dedicated to operate and maintain smart contracts in a permissionless, flexible and scalable manner. This way, Evernode allows more flexible and advanced applications to be built on the platform rather than using lite smart contracts (Hooks) that can only facilitate a limited amount of capabilities within the bounds of the XRPL's native protocol, which was not created with customizability and flexibility in mind. A node on a smart contract cluster is called a HotPocket node, it is a secured container in an Evernode Host which is autonomously managed by a daemon called Sashimono. The daemon has multiple responsibilities such as managing all incoming hosting requests (redeems) and provisioning smart contract instances in secured containers. HotPocket nodes are independent from the XRP Ledger, they're not a part of the XRP Ledger. Diagram 1: An Evernode Host's high level structure (simplified) The Evernode ecosystem consists of 4 parts to fully operate seamlessly: 1. Evernode Hook 2. HotPocket 3. Sashimono 4. The XRP Ledger's native DEX We'll divide these complicated components into different sections and explain it to you in this post based on our own understanding. Evernode's components 1. Evernode Hook The Evernode Hook is one of the most essential parts of Evernode. With Hooks enabled on the XRPL mainnet, Evernode is able to establish an on-chain platform to connect all the participating parties, maintain a governance platform (DAO), and efficiently control the issuance and distribution of Evers to reliable hosts through audits. The Evernode Hook has multiple responsibilities that are crucial to the ecosystem: - controlling the issuance and distribution of Evers - verifying node membership in Evernode - tracking node performance through audits - governing the servicing of smart contract Hosting Requests submitted by L1 Evernode users - maintaining Evernode's configuration parameters All participating parties on Evernode use XRPL transactions with attached memos to incorporate Evernode operation payloads: - Evernode Hosts: host registration/deregistration - Auditors: audit request/results - Evernode users: redeem request/results Utilizing memos allows participating parties to transmit data on the XRPL between each other. For instance, an Evernode Host will create an XRPL account and register to Evernode through the Hook, it'll look something like this: The Evernode Hook defines a set of tunable configuration parameters to govern the rules of the system, which can be changed in a permissionless manner via a governance vote on the XRPL. The following parameters are tunable via the governance system: - max supply of Evers - number of Evers rewarded per Moment - number of ledgers per Moment - host registration fee - max number of ledgers within which a redeem request has to be serviced - number of maximum hosts that can be audited by an Auditor per Moment - and much more... 2. HotPocket HotPocket is a UNL-based consensus engine. It manages all consensus related matters in a smart contract cluster with other nodes to maintain a distributed, canonical state of a smart contract. HotPocket allows smart contracts to operate within their own independent cluster with its own chain history and with its own set of nodes. This results in smart contracts being flexible as clusters may be configured to consist of a specific type of node to best fit their smart contract and its intended use case. Diagram 2: Evernode Hosts that are hosting the same 3 smart contract instances Each smart contract cluster operates independently and does not interfere with other clusters. 3. Sashimono HotPocket converts any number of nodes into a smart contract cluster. The rollout of a HotPocket smart contract currently requires manual setup of a smart contract instance in each participating host, which presents scaling issues. From a production standpoint, it's preferable to dedicate a selection of servers for the collective purpose of running logical nodes from various different HotPocket contracts from time to time, and then coordinate these from a unified and decentralized command point. Without Sashimono, HotPocket is a centralized smart contract solution. Generally, a single actor would be required to spin-up and configure the relevant nodes in a smart contract cluster. Sashimono is the daemon that allows smart contract clusters to be spun up in a permissionless and scalable manner without needing to manually setup a smart contract instance in every participating node. 4. The XRPL's DEX The XRPL’s native decentralized exchange (DEX) plays a central role in how users and Evernode Hosts interact with one another, enabling the exchange of hosting services for units of value. Since each Evernode Host will offer its own unique set of performance characteristics fit for various use-cases, there needs to be a way for the market to distinguish the value of services offered by each Host. Evernode facilitates the differentiation of services each Host provides in a novel way through the use of Hosting Tokens, the value of which is determined by the free market on the XRPL DEX. Hosting Tokens are non-divisible tokens minted by Evernode Hosts which can be redeemed in exchange for the services offered by the Host that minted them. The following steps are a high level summary of the flow and lifecycle of Hosting Tokens within the Evernode ecosystem: 1. Hosts mint Hosting Tokens and list them on the XRPL DEX 2. Users exchange $EVRs for Hosting Tokens 3. User sends Hosting Tokens with memo describing instance requirements to the Hook 4. Upon observing the user’s transaction to the Hook, the Host then sends a small XRP transaction to the Hook containing details of the created instance in the memo field 5. The Hook sends the user’s Hosting Tokens to the Host, where the requested computational services are rendered (additional resources can be paid for in Evers) The DEX's Quality Control One important benefit of the DEX is its inherent capacity to police the quality of the nodes via the law of supply and demand. The best signal of a node’s quality and trustworthiness is the natural price discovery of its Hosting Tokens on the DEX. Unreliable nodes should quickly be exposed and their tokens shunned or under-priced relative to their peers' tokens. In this way, the DEX provides an important circuit-breaker function, allowing unreliable or poor quality nodes to be easily auto-identified by dApps and dApp developers. ------------------ Credits Wo Jake - Author effofexx - Reviewer Note: Learn more about Evernode: - Hooks vs Evernode Links and resources: - Evernode Documentation - Evernode Whitepaper v1.0 - Evernode Hook codebase - Evernode Community (Reddit) - Evernode Media (Twitter) - Sashimono's Design

The Hooks amendment, if approved, will provide smart contract capabilities to the XRP Ledger by allowing pieces of code to execute logic before and/or after transactions, controlling their flow and behavior. Hooks are powerful if used and developed properly combined with the XRPL's features, Evernode is offering a unique flexible solution to smart contract developers. Evernode allows complex business ideas and smart contracts like Chainlink, NuCypher and Storj to be deployed and hosted by leveraging the flexibility of its off-chain solution. The off-chain solution allows developers to be more flexible with their smart contract as the underlying network itself is dedicated to serve its kind. Evernode is very flexible compared to Hooks, Hooks can only execute logic on the XRPL because the XRPL's validators are not oracle providers or storage nodes but HotPocket nodes can be. A Hook is a layer 1 smart contract because the XRP Ledger is the underlying protocol 'hosting' it; it's decentralized and secure but not flexible. A Hook can perform mathematics, store small bits of data, and execute logic but can't go beyond a certain limit as the XRP Ledger's validators' main purpose is to validate transactions. XRPL validators are not designed to store massive amounts of data, perform complex computation, or access off-chain data on behalf of smart contracts. Evernode utilizes Hooks as a way to connect all the participating parties together on-chain. A HotPocket smart contract can store massive amounts of data, perform complex computations, act as an oracle solution, or even act as a decentralized bridge between payment networks (xrpl<->eth). A Hook is very powerful combined with the XRP Ledger's features and Evernode is very flexible as developers have a plethora of options when configuring their smart contract's cluster. This means that developers will be able to select nodes fit for their purpose, selecting from options including: - large storage space - high RAM - large computational resources (CPU) - reliability and trustworthiness (consensus agreement and decentralization) - nodes owned by the developer (centralized solution) HotPocket smart contract developers have a choice to configure how many nodes are constitute of their smart contract's cluster, which nodes belong to their cluster and, whether the cluster is permissioned or permissionless to best fit their smart contract and its intended use case. With layer 1 smart contracts or Hooks, this is not possible as the underlying network (XRPL) is in charge of custody. Developers wishing to create smart contracts directly on the XRPL must work within the bounds of the native protocol which was not created with customizability in mind, whereas Evernode is being created to extend the usefulness of the XRPL by enabling developers to create and deploy any smart contract that they can think of on a flexible layer 2 solution. HotPocket smart contracts can be written in any POSIX compliant programming language, whereas Hooks can only be written in any language compilable to WebAssembly.