AUTOMATIC VALUE DISTRIBUTION IN DECENTRALIZED PROTOCOLS

Abstract

Example methods and systems are directed to performing value distribution in a self-sustaining manner in the context of a decentralized finance protocol. One or more self-executing contracts are deployed to a blockchain network to cause association of an asset pool with a plurality of asset providers. One or more of the asset providers stake pool tokens against the asset pool. The one or more self-executing contracts cause tracking of performance of the asset pool in a sliding time window by applying a predetermined performance metric. A weight of the asset pool is automatically updated by applying a predetermined weight metric that is based on the performance of the asset pool. The one or more self-executing contracts perform value distribution to the asset pool based on the weight of the asset pool.

Description

CLAIM OF PRIORITY

This application claims the benefit of priority to U.S. Provisional Application Ser. No. 63/396,047, filed on Aug. 8, 2022, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

Subject matter disclosed herein generally relates to blockchain technology. More specifically, but not exclusively, the subject matter herein includes methods and systems for automatically performing value distribution to asset pools used in decentralized protocols, such as decentralized finance protocols.

BACKGROUND

A decentralized finance protocol, often referred to as a “DeFi protocol,” includes formats, codes, or procedures governing the use of digital assets on a blockchain network. A DeFi protocol often needs liquidity to function effectively. However, users may be unlikely to deposit assets in a DeFi protocol without sufficient incentives. Yield farming is a technique that is used to incentivize users to deposit assets on a DeFi protocol, e.g., to provide liquidity to an asset pool. In exchange for depositing assets, a user may receive pool tokens representing their share of the assets in a pool. These pool tokens can then be staked, e.g., by depositing them into “farms,” making a user eligible for value distribution. In some cases, value distribution includes issuing rewards, such as governance tokens that provide protocol voting rights.

However, integrating yield farming into a DeFi protocol may result in a number of technical challenges. For example, a significant degree of manual input or control may be required in the value distribution process, e.g., to manage or issue rewards. In some cases, developers may need to allocate rewards manually, creating a potential point of system failure, e.g., if developers miss an update. Manual value distribution or allocation also introduces the possibility of subjectivity, bias, or even unscrupulous activity. Further, a DeFi protocol may distribute value in such a manner that top performing asset pools receive a disproportionate share of value, and thus a disproportionate share of control over the DeFi protocol itself This may create a negative, self-feeding cycle in which a small subset of users govern important aspects such as reward distribution, in turn reducing transparency, asset security, or broad adoption of the DeFi protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings. In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced. Some non-limiting examples are illustrated in the figures of the accompanying drawings in which:

FIG. 1 is a block diagram illustrating various layers of a DeFi system, according to some examples.

FIG. 2 is a diagrammatic representation of a networked computing environment suitable for deploying self-executing contracts and providing a DeFi protocol interface, according to some examples.

FIG. 3 is a diagrammatic representation of the deployment of a plurality of self-executing contracts to a blockchain network to distribute value in a DeFi protocol, according to some examples.

FIG. 4 is a diagrammatic representation of users interacting with a plurality of asset pools of a DeFi protocol on a blockchain network, according to some examples.

FIG. 5 is a flowchart illustrating a method suitable for deploying self-executing contracts to a blockchain network to register, track the performance of, and perform value distribution to asset pools of a DeFi protocol, according to some examples.

FIG. 6 is a flowchart illustrating a method suitable for facilitating user interaction with an asset pool of a DeFi protocol, according to some examples.

FIG. 7 is a block diagram showing a software architecture for a computing device, according to some examples.

FIG. 8 is a block diagram of a machine in the form of a computer system, according to some examples, within which instructions may be executed for causing the machine to perform any one or more of the methodologies discussed herein.

DETAILED DESCRIPTION

Examples disclosed herein provide methods and systems that enable or facilitate yield farming. Example systems disclosed herein are decentralized, tamper-proof, and self-balancing. Techniques are described to provide enhanced inclusivity of asset pools of a DeFi protocol in the context of value distribution without requiring manual intervention, e.g., from developers or interface providers, subsequent to deployment.

The term “blockchain network,” as used herein, refers to a digital, decentralized, and distributed system, network, or configuration of systems, in which data is stored in multiple records (e.g., “blocks”) that are cryptographically linked to each other. Each record or block may contain a list of transactions or other forms of data records, and may be connected to each other through a cryptographic hash function, thus forming a chain. A blockchain network may comprise a single blockchain structure, or multiple, interrelated blockchain systems, e.g., interconnected blockchains, sidechains, or child chains. A blockchain network may include public, private, or hybrid blockchains.

A blockchain network may provide a digital ledger of transactions that is duplicated and distributed across a network of computer systems. Blockchain networks may utilize different consensus mechanisms to validate and verify transactions or data blocks, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), or Delegated Proof-of-Stake (DPoS). A blockchain network accommodates the use of self-executing contracts (e.g., “smart contracts”), DeFi protocols, decentralized applications (“dApps”), non-fungible tokens, blockchain-based data storage, or other applications, services, or tools that are deployable on a blockchain.

DeFi protocols have shown potential to change the financial industry by providing decentralized technology. DeFi protocols typically rely on self-executing contracts to perform transactions directly on a blockchain network, thus removing the traditional requirement of an intermediary. A DeFi protocol may provide a Decentralized Exchange (DEX). A DEX is a platform that allows users to trade digital assets without the need for an intermediary. Examples of DeFi protocols include Aave™, yEarn™, Uniswap™, Synthetix™, and Compound™.

DeFi protocols typically require liquidity to operate as intended, and many DeFi protocols incentivize users to deposit liquidity or other assets on a DeFi protocol. A user that deposits or invests assets in this manner is referred to herein as an “asset provider.” It is noted that an asset provider may be a human user, a non-human user (e.g., a “bot”), or a combination thereof.

Examples described herein address or alleviate the technical challenges referred to above by providing an autonomous system (e.g., a yield farming system) that can manage asset pools and value distribution, e.g., issuing of rewards, in a self-sustaining manner. According to some examples, one or more self-executing contracts are deployed on a blockchain network to cause association of an asset pool with a plurality of asset providers. The blockchain network may be used to implement a DeFi protocol, e.g., the blockchain network is the underlying blockchain on which the DeFi protocol operates. The pool tokens may represent respective shares of the plurality of asset providers in the asset pool.

One or more of the asset providers may stake pool tokens against the asset pool. The one or more self-executing contracts cause tracking of performance of the asset pool in a sliding time window by applying a predetermined performance metric. The sliding time window may have a predetermined duration, e.g., 7 days, 14 days, 21 days, or 30 days. A weight of the asset pool is automatically updated by applying a predetermined weight metric that is based on the performance of the asset pool. In some examples, a system may include only one asset pool. In other examples, a system may include a plurality of asset pools. In the latter case, performance of the asset pool may be determined or assessed relative to performance of one or more other asset pools.

Performance may be tracked within the sliding time window. The one or more self-executing contracts perform value distribution to the asset pool based on the weight of the asset pool. In some examples, value distribution involves issuing rewards.

Value distributed to the asset pool may be available to the one or more asset providers with staked pool tokens. For example, the value may be in the form of reward tokens distributable to the one or more asset providers based on their staked pool tokens.

In some examples, the asset pool and the one or more other asset pools are in a group of asset pools associated with the DeFi protocol, e.g., a group of asset pools registered with a farming system of or associated with the DeFi protocol. Value may be distributed based on the weight of each asset pool relative to a global weight of the group of asset pools. The weight may be a time-scaled weight.

In some examples, a method includes causing generation of the asset pool on the blockchain network and issuing of the pool tokens to the plurality of asset providers. The method may include detecting, by the one or more self-executing contracts, that the asset pool meets one or more value distribution criteria (e.g., rewards criteria), and responsive to detecting that the asset pool meets the one or more value distribution criteria, designating the asset pool as value distribution-eligible (e.g., rewards-eligible) on the blockchain network. The value distribution criteria may include one or more of: a minimum duration of pool existence, a minimum number of asset providers, or a minimum pool value.

Where value distribution involves issuing rewards, different types of rewards may be issued, depending on the implementation. In some examples, the rewards comprise reward tokens, e.g., governance tokens of the DeFi protocol. The reward tokens may be fungible tokens usable within the context of the DeFi protocol. The reward tokens may, in some examples, provide voting rights. In some examples, the pool tokens are fungible tokens (e.g., usable to redeem a share of assets in an asset pool).

The one or more self-executing contracts may be deployed so as to release value based on a schedule, e.g., from an escrow. For example, reward tokens can be released from a reward token escrow based on a decreasing release schedule, withdraw the released reward tokens from the reward token escrow, and allocate at least some of the released reward tokens to an asset pool. The decreasing release schedule may be a schedule that generates scarcity of value, e.g., scarcity of reward tokens. The schedule may be a halving schedule.

Systems as described herein may provide a user interface, e.g., to facilitate interactions between users (e.g., asset providers) and a DeFi protocol on a blockchain network. For example, the user interface may be used to transmit messages to a user, e.g., messages indicative of value distributed to the asset pool, value or rewards allocated to the user, performance of the asset pool, or the like. The user interface may also receive instructions, such as transaction instructions, and facilitate broadcasting of transactions to the blockchain network.

Existing yield farming systems may depend on frequent updates from developers to distribute value such as rewards, creating a potential point of failure and introducing risks, such as security or transparency risks, or the risk of unscrupulous activities. Examples described herein address or alleviate these technical hurdles through a decentralized, self-sustaining yield farming system. The system uses self-executing contracts to automatically track performance over discrete periods, update pools weights, unlock value, and distribute value. In some examples, the system described herein is protocol-agnostic and can easily be integrated into various types of DeFi protocols or projects. For example, a DeFi protocol may integrate a yield farming system as described herein by calling relevant functions of its self-executing contracts, e.g., in response to a transaction being executed against an asset pool, the DeFi protocol may automatically call a function of the yield farming system to update pool weights and distribute rewards.

Examples described herein may provide a value distribution system that is secure and sustainable for as long as its underlying blockchain network continues to operate. Once the system is deployed, it may operate without the need for developers to perform updates or initiate decisions, such as weight adjustments, and automatically incentivizes users to register pools or perform transactions (e.g., by releasing rewards based on a decreasing release schedule). Examples described herein may also provide techniques for enhancing inclusiveness, e.g., by making all registered asset pools with recent unrealized profits eligible to receive value based on their performance relative to other asset pools.

When the effects in this disclosure are considered in aggregate, one or more of the methodologies or systems described herein may obviate a need for certain efforts or resources that otherwise would be involved in DeFi protocols or yield farming systems. Computing resources used by one or more machines, nodes, databases, or networks may be more efficiently utilized or even reduced, e.g., as a result of automatic or self-executing management of value distribution operations that reduces interactions between end user computing devices and blockchain network nodes. Examples of such computing resources may include processor cycles, network traffic, memory usage, processing unit resources, data storage capacity, power consumption, and cooling capacity.

FIG. 1 is a block diagram illustrating various layers of a DeFi system 102, according to some examples. As mentioned, a “DeFi” (Decentralized Finance) system is able, through the use of technology, to offer financial instruments without relying on intermediaries, such as brokerages, exchanges, or banks. The DeFi system 102 of FIG. 1 utilizes self-executing contracts on a blockchain network, as described below.

The DeFi system 102 may include one or more layers, such as those shown in FIG. 1. FIG. 1 shows an application layer 104, an aggregation layer 106, a protocol layer 108, an asset layer 110, and a settlement layer 112. One or more of the layers shown in FIG. 1 may work together or interact to provide a comprehensive and decentralized solution.

Referring firstly to the asset layer 110, the asset layer 110 is a foundational layer of the DeFi system 102 that hosts or provides one or more assets, such as cryptocurrencies. These assets may take the form of tokens on a blockchain network, e.g., Ethereum™ or Celo™ (both open-source blockchain platforms that enable self-executing contracts). The assets may thus be referred to, at least in some cases, as tokenized assets. Various asset types may be supported, e.g., native blockchain assets such as ETH (in the case of Ethereum™), stablecoins, tokens representing real-world commodities (e.g., gold), or tokens tied to a particular DeFi project. Tokens may include fungible and/or non-fungible tokens.

Turning to the protocol layer 108, this layer comprises self-executing contracts. A self-executing contract, e.g., “smart contract,” may set rules or guidelines for how assets can be mobilized, traded, lent, borrowed, staked, or the like. Self-executing contracts may also set rules or guidelines for how value is distributed or rewards are issued, e.g., in a yield farming system comprising multiple asset pools. A DeFi protocol, such as one of the example protocols mentioned above, may be situated in the protocol layer 108. A DeFi protocol may have a specific set of rules and logic, articulated and enforced within its respective self-executing contracts. The protocol layer 108 may thus enable functionality relating to, for example, asset management 114, exchange 116, lending 118, or derivatives 120, as shown in FIG. 1.

The application layer 104 facilitates user interaction with one or more DeFi protocols. The application layer 104 may be a user-facing layer that delivers a user interface (e.g., a graphical user interface of a software application or web application). The application layer 104 may simplify tasks such as swapping tokens, investing assets, providing liquidity, borrowing assets, or redeeming rewards, all of which may require a degree of interaction with the underlying protocols.

The DeFi system 102 may include the aggregation layer 106 to aggregate data or functionality, e.g., from various protocols. The aggregation layer 106 may include services that channel transactions via multiple protocols, e.g., to provide reduced fees or specific functionality. The aggregation layer 106 may implement aspects of a yield farming system or platform, e.g., to migrate assets between protocols to optimize returns.

Referring finally to the settlement layer 112, in some examples, the settlement layer 112 refers to the blockchain network. For example, the settlement layer 112 may comprise the underlying blockchain of a DeFi protocol, where self-executing contracts are deployed, and where transactions are reconciled and recorded. For example, the Ethereumυ blockchain or Celo™ blockchain may serve as the settlement layer 112. The settlement layer 112 provides a decentralized and secure method to authenticate and chronicle all transactions. The settlement layer 112 enables automatic execution of self-executing contracts, e.g., in response to the fulfilment of predetermined conditions or in response to the calling of functions within those self-executing contracts.

The one or more layers of the DeFi system 102 may contribute to a decentralized and transparent ecosystem. This may, for example, enable features such as lending or borrowing funds directly, speculating on price movements of assets using derivatives, trading of cryptocurrencies, insuring against risks, and earning interest in savings-like accounts, without traditional intermediaries.

It is noted that a layered architecture is shown in FIG. 1 primarily for illustrative purposes. Interactions between “layers” may be complex, e.g., the application layer 104 may interact with the asset layer 110 directly or via one or more other layers. The DeFi system 102 can be implemented using a combination of software and hardware components. Two or more of the layers of FIG. 1 may be combined into a single layer, and the functions described herein for a single layer may be subdivided among multiple layers. Furthermore, according to various examples, aspects of a layer described herein may be performed by a single machine, database, or device, or may be distributed across multiple machines, databases, or devices, e.g., interconnected through a network.

FIG. 2 is a diagrammatic representation of a networked computing environment 200 in which aspects of some examples of the present disclosure may be implemented or deployed. One or more servers in a server system 204 provide server-side functionality via one or more networks 202 to a networked device, in the example form of a user device 206 that is accessed by a user 208. The user 208 may be a user of a DeFi protocol, e.g., an asset provider in one or more asset pools of the DeFi protocol, or a user that otherwise interacts with self-executing contracts of the DeFi protocol to perform transactions.

A web client 212 (e.g., a browser) or a programmatic client 210 (e.g., an “app”) may be hosted and executed on the user device 206. An Application Program Interface (API) server 220 and a web server 222 provide respective programmatic and web interfaces to components of the server system 204. A specific application server 218 hosts a deployment system 224 and an interface system 226, each of which includes components, modules, or applications.

The user device 206 can communicate with the application server 218, e.g., via the web interface supported by the web server 222 or via the programmatic interface provided by the API server 220. It will be appreciated that, although only a single user device 206 is shown in FIG. 2, a plurality of user devices may be communicatively coupled to the server system 204 in some examples. Further, while certain functions are described herein as being performed at either the user device 206 (e.g., web client 212 or programmatic client 210) or the server system 204, the location of certain functionality either within the user device 206 or the server system 204 may be a design choice. In some examples, particular technology and functionality may be deployed within the server system 204. In other examples, such technology and functionality may be deployed within a programmatic client.

The application server 218 is communicatively coupled to database servers 228, facilitating access to an information storage repository or database 230. In some examples, the database 230 includes storage devices that store information to be processed or transmitted by the deployment system 224 or by interface system 226, e.g., details of self-executing contract or details of transactions or value distribution.

The application server 218 uses the deployment system 224 to deploy a set of self-executing contracts to a blockchain network 236 in order to provide certain functionality of or in relation to a DeFi protocol or DeFi system, e.g., the DeFi system 102 of FIG. 1. The user 208 may interact with the blockchain network 236 as part of a yield farming strategy, e.g., provide liquidity, earn value (e.g., reward tokens, assets, or cash), and stake value (e.g., reward tokens) in the DeFi protocol.

The blockchain network 236 may be a network of computing devices or computing nodes (e.g., a peer-to-peer network) that stores and manages at least one blockchain. The blockchain is a list of records, called blocks, that are cryptographically linked. In some examples, the blockchain network 236 is a Celo™ blockchain network. In some examples, the blockchain network 236 is an Ethereum™ blockchain network. The blockchain network 236 may store blocks, calculate new blocks, process transactions (e.g., via self-executing contracts) and the like. Examples of self-executing contracts are described with reference to FIGS. 3-6 below.

The application server 218 further accesses application data (e.g., application data stored by the database servers 228) to provide an application to the user device 206 via a web interface 232 or an app interface 234. The application may be a DeFi application, e.g., provided as part of the application layer 104 of FIG. 1. The DeFi application may facilitate user interaction with the DeFi protocol or DeFi system on the blockchain network 236, e.g., facilitate transactions that the user wishes to perform. The user 208 may access the DeFi application using a dedicated programmatic client 210 (e.g., installed on a computing device, such as a desktop computer or a portable computing device), with some functionality being provided client-side and other functionality provided server-side. Some or all functionality of the DeFi application may thus be deployed by a programmatic client 210 executing on the user device 206.

In some examples, the user 208 may either directly access the blockchain network 236 (e.g., by calling self-executing contract functions directly via the network 202) via the network 202 or utilize functionality of the DeFi application to facilitate or simplify accessing of the blockchain network 236. The interface system 226 may provide a GUI via the app interface 234 or the web interface 232 that enables the user 208 to provide input data and view or receive outputs generated by the interface system 226. For example, the GUI may enable the user 208 to request trades (e.g., swapping tokens or providing liquidity) and to receive messages with information, such as information relating to an asset pool in which the user 208 is an asset provider, e.g., rewards issued to the asset pool.

In some examples, the DeFi application is designed to “abstract away” certain technical aspects of blockchain transactions, making it easier for users to interact with a DeFi protocol. For example, the DeFi application may simplify token selection, transaction approval, liquidity provision, investments, or gas fees, and may make it easier for users to view data such as transaction status, investment status, or rewards status.

To access the DeFi application provided by the interface system 226, the user 208 may create an account with an entity associated with the server system 204, e.g., a service provider (or access an existing account with the entity). The user 208 may use account credentials to access the app interface 234 or web interface 232 (via a suitable web browser) and request access to the DeFi application.

The DeFi application may integrate with a wallet that facilitates transactions on the blockchain network 236. Alternatively or additionally, the user may have a wallet running on the user device 206. The wallet may be used, for example, to manage and store private keys securely. In some examples, when a transaction is initiated on the GUI of the interface system 226, the wallet signs the transaction with the private key. This signed transaction provides cryptographic proof that the transaction is authorized by the holder of the wallet without revealing the private key itself. Once a transaction is signed, it may be propagated through the blockchain network 236 via nodes in the blockchain network 236. The transaction may be in a pending stage at first, after which it may be picked by a miner or validation and included in a next block. When a transaction is included in a block, the relevant self-executing contract on the blockchain network 236 carries out the instruction set in the transaction. For instance, in the case of a token swap, the self-executing contract ensures that the swap happens at an agreed rate, transferring tokens between the relevant addresses. The wallet may then update a balance and transaction state, which may be reflected on the GUI of the DeFi application.

One or more of the application server 218, the database servers 228, the API server 220, and the web server 222 may each be implemented in a computer system (e.g., a personal computer, a tablet computer, or a mobile phone), in whole or in part, as described below with respect to FIG. 8. In some examples, third-party applications, such as a third-party application 216 executing on a third-party server 214, can communicate with the application server 218 via the programmatic interface provided by the API server 220. For example, a third-party application may support one or more features or functions on a website or platform hosted by a third party, or may perform methodologies described herein and provide input or output information to the application server 218 for further processing or publication. For example, the third-party application 216 may be an asset management application that utilizes the DeFi protocol implemented on the blockchain network 236. The asset management application may send certain data to the application server 218, e.g., details of user investments and transactions, and receive certain data from the application server 218, e.g., details of user transactions or value distribution.

The network 202 may be any network that enables communication between or among machines, databases, and devices. Accordingly, the network 202 may be a wired network, a wireless network (e.g., a mobile or cellular network), or any suitable combination thereof The network 202 may include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof.

Any one or more of the components (e.g., systems or modules) described herein may be implemented using hardware (e.g., a processor of a machine) or a combination of hardware and software. For example, any component described herein may configure a processor to perform the operations described herein for that component. Moreover, any two or more of these components may be combined into a single component, and the functions described herein for a single component may be subdivided among multiple components. Furthermore, according to various examples, components described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.

FIG. 3 is a diagram 300 illustrating the deployment of a plurality of self-executing contracts 302 to the blockchain network 236 of FIG. 2 to provide value distribution and other functionality in a DeFi protocol, according to some examples. The self-executing contracts 302 may be deployed by the deployment system 224 of FIG. 2 and this configuration is illustrated in FIG. 3.

The self-executing contracts 302 are configured to perform value distribution through the issuing of rewards, such as reward tokens. However, it will be appreciated that similar contracts or techniques may be employed for other types of value distribution, such as interest payments, asset allocations, fees, dividends, cash, airdrops to wallet addresses, non-fungible token (NFT) rewards, or the like.

The self-executing contracts 302 are shown to include the following internal contracts 304: a pool manager contract 306, a staking rewards factory contract 308, a staking rewards contract 310, a release schedule contract 312, and a release escrow contract 314. The self-executing contracts 302 are shown to further include an external contract 316 in the example form of a pool contract 318. In some examples, the internal contracts 304 are self-executing contracts associated with a yield farming system or value distribution system, while the external contract 316 is a self-executing contract of a DeFi protocol that integrates the yield farming or value distribution system into the DeFi protocol, e.g., a liquidity pool protocol or an asset management protocol.

Referring firstly to the pool manager contract 306, in some examples, the pool manager contract 306 may be referred to as the “main contract” of the internal contracts 304. The pool manager contract 306 may be responsible for one or more of: generating or registering asset pools on the blockchain network 236, marking pools as eligible to receive rewards (e.g., after they meet rewards criteria), updating a pool weight each time a state of an asset pool is updated (e.g., through an external transaction conducted against the asset pool), and withdrawing unlocked or released reward tokens from a reward token escrow.

In some examples, the pool manager contract 306 includes predetermined algorithms, calculations and/or formulas for performing certain functions, such as tracking asset pool performance and updating pool weights. The pool manager contract 306 may define a predetermined performance metric and/or a predetermined weight metric, as described further below.

The staking rewards factory contract 308 is an example of a factory contract and is responsible for deploying the staking rewards contract 310 in response to the registering or generation of an asset pool. Asset providers can deposit assets in the asset pool and receive pool tokens that represent their respective shares of the assets in the asset pool.

The staking rewards contract 310 is a rewards contract that is an example of a value distribution contract, and is designed to represent a “farm.” The staking rewards contract 310 is associated with an asset pool and receives rewards (if any) from the pool manager contract 306. Users, e.g., asset providers, can stake pool tokens in this contract to earn a share of the rewards of the asset pool, proportional to their respective stakes. In some examples, the farm receives rewards whenever the state of its associated asset pool is updated, e.g., when an external transaction, such as depositing or withdrawing, is performed against the relevant asset pool. In other examples, the farm only receives the relevant rewards when a user initiates a claim, e.g., a rewards claim.

As mentioned, in some examples, the rewards allocated to an asset pool may include reward tokens, e.g., governance tokens of the relevant DeFi protocol. In some examples, the number of reward tokens available for a user can be calculated using the formula below, where x is the number of reward tokens available for the user, buser is the number of pool tokens the user has deposited in the farm, r is the current reward per token stored, r_user is the reward per token stored when the user last claimed rewards, and x_user is the number of unclaimed reward tokens the user accumulated when they last deposited or withdrew from the farm. The formula below may be built into the staking rewards contract 310.

x=(b_user*(r−r_user))+x_user

In some examples, a global reward per token stored is defined so as to be strictly increasing to prevent unclaimed user rewards from decreasing whenever the total supply of deposited pool tokens changes. Whenever a user deposits or withdraws from the farm, r_user is set to r and pending rewards are added to x_user to prevent the change in the number of deposited pool tokens from affecting the pending rewards of the user. Whenever a user claims rewards, x_user is set to zero and r_user is set to r.

Referring now to the release schedule contract 312, as mentioned, reward tokens may be released according to a decreasing release schedule. The release schedule contract 312 may be used for calculating the number of reward tokens unlocked based on the time elapsed since the contract was deployed. Tokens may be unlocked on a halving (also referred to as “halvening”) schedule. The schedule may consist of an infinite number of cycles, each lasting a predetermined period of time, e.g., 20 weeks, 26 weeks, or 32 weeks. When a halving schedule is employed, each cycle distributes half as many tokens as the previous cycle, creating artificial scarcity for the reward tokens. It is noted, however, that the release schedule may be customized prior to deployment to suit requirements.

In some examples, the reward rate can be calculated using the following formula, where r is the reward rate, n is the number of tokens distributed in the first cycle, i is the index of the cycle, and d is the duration of the cycle (in seconds). The formula below may be built into a self-executing contract, such as the release schedule contract 312.

$r=\left\{\begin{array}{cc}\frac{n}{2^{i-1}*d},& \mathrm{if}i>0\\ 0,& \mathrm{if}i=0\end{array}\right\}$

In some examples, the available rewards can be calculated using the following formula, where x is the amount of rewards available, t_s is the start time of the current cycle, t_l is the last time rewards were claimed, t_c is the current time, and r is the reward rate calculated previously. The formula below may be built into a self-executing contract, such as the release schedule contract 312.

$x=\left\{\begin{array}{cc}\left[\left(t_s-t_l\right)*2r\right]+\left[\left(t_c-t_s\right)*r\right],& \mathrm{if}{t}_l<t_s\\ \left(t_c-t_l\right)*r,& \mathrm{if}{t}_l\ge t_s\end{array}\right\}$

The pool manager contract 306 may be configured to call the release escrow contract 314 to release reward tokens. In some examples, the release escrow contract 314 acts as a reward token escrow and stores the lifetime supply of reward tokens to distribute. The release escrow contract 314 uses the release schedule of the release schedule contract 312 to determine how many tokens to unlock at any given time. In some examples, the pool manager contract 306 automatically calls the release escrow contract 314 whenever the weight of an asset pool is updated (as further described below) or a user claims rewards (as also further described below).

The external contract 316, or multiple external contracts, may depend on the implementation. In the example of FIG. 3, the external contract 316 is the pool contract 318, which represents a decentralized hedge fund that is part of an external asset management protocol. The asset management protocol integrates the farming or value distribution system by, for example, calling an “update pool weight” function of the pool manager contract 306 in response to a user depositing or withdrawing from an asset pool, or in response to the owner of an asset pool executing a transaction on behalf of the asset pool.

In some examples, when registering an asset pool with the farming or value distribution system, a transaction is initiated by the pool contract 318 to call a “register pool” function of the pool manager contract 306. Initially, an asset pool may not be eligible for rewards. However, and as described further below, the Average Price Change (APC) and/or unrealized profits may be tracked per period to ensure that the weight of an asset pool can be calculated after it is marked as eligible.

An asset pool may be required to meet one or more value distribution criteria, e.g., rewards criteria. For example, the asset pool may be required to meet one of the following rewards criteria: a minimum duration of pool existence (e.g., 30 days), a minimum number of asset providers (e.g., 10 unique investors), or a minimum pool value (e.g., $1000). Once the asset pool meets one or more of the value distribution criteria, this may be detected by the pool contract 318, and the pool contract 318 automatically initiates a transaction on the blockchain network 236 to mark the asset pool as value distribution-eligible (e.g., rewards-eligible).

To integrate the farming or value distribution system provided by the internal contracts 304 into a DeFi protocol, the internal contracts 304 are deployed to the blockchain network 236 and the lifetime supply of reward tokens are transferred to the release escrow contract 314, e.g., before a start time provided in the release schedule contract 312. In the DeFi protocol that integrates the internal contracts 304, a function that creates an asset pool may, for example, call a pool registration function (e.g., “PoolManager.registerPool” function of the pool manager contract 306) as a last statement. Further, each function that allows users to interact with an asset pool (e.g., deposit, withdraw, or exit) may, for example, call a pool weight updating function (e.g., “PoolManager.updateWeight()” function of the pool manager contract 306) as a last statement. Further, a suitable function may wrap a value distribution-eligible marking function (e.g., “PoolManager.markAsEligible()” function of the pool manager contract 306) that is then called once a pool is registered.

The self-executing contracts shown in FIG. 3 are shown to illustrate certain examples and are not intended to be restrictive examples. It is noted that, in some examples, two or more of the self-executing contracts shown in FIG. 3 may be combined into a single contract, and functions described herein for a single contract may be subdivided among multiple contracts. For example, in other cases, the internal contracts 304 may include separate self-executing contracts for one or more of: determining asset pool weights, tracking asset pool performance, receiving rewards, or assigning rewards.

Main contracts, e.g., contracts that are not deployed by factory contracts, may, for example, be deployed using the “Ethers” Javascript library. “Ethers” is a Javascript library that allows interacting with the Ethereum™ blockchain from Javascript applications, and it can be used to deploy self-executing contracts. A contract may be deployed from a one-time script, e.g., a script that runs once to deploy each contract.

FIG. 4 is a diagram 400 showing a plurality of users in the example form of asset providers 412, 414, 416, 418, and 420. Each of the asset providers 412, 414, 416, 418, and 420 has a user device 402, 404, 406, 408, 410. One or more of the user devices 402, 404, 406, 408, 410 may be similar to the user device 206 of FIG. 2.

Each asset provider 412, 414, 416, 418, and 420 uses their respective user device 402, 404, 406, 408, 410 to access the self-executing contracts 302 of FIG. 3 after the self-executing contracts 302 are deployed to the blockchain network 236. As depicted in FIG. 4, the asset providers 412, 414, 416, 418, and 420 can access the blockchain network 236 directly or can use the interface system 226, e.g., the DeFi application described with reference to FIG. 2, to facilitate or simplify performing transactions.

FIG. 4 also shows a plurality of asset pools 422, 424, 426. The asset providers 412, 414, 416, 418, and 420 may perform transactions against one or more of the asset pools 422, 424, 426, e.g., the asset provider 412 may have provided assets to provide liquidity or investment into the asset pool 422, and may perform transactions against the asset pool 422 by interacting with the self-executing contracts 302 on the blockchain network 236.

As mentioned, the relevant DeFi protocol may integrate the internal contracts 304 to provide various functionality, including staking rewards. To this end, when the asset pools 422, 424, 426 become registered with the yield farming system on the blockchain network 236, a staking rewards contract 310 is generated for each asset pools 422, 424, 426 to define respective farms 428, 430, 432.

In some examples, the DeFi protocol is an asset management protocol. In such cases, the asset provider 412 receives pool tokens representing their share of the assets invested in the asset pool 422. By integrating the self-executing contracts 302 into the asset management protocol, the asset management protocol receives the “farming” functionality described with reference to FIG. 3. For example, the staking rewards contract 310 generates a staking rewards contract associated with the asset pool 422 to define the farm 428. The asset provider 412 can then stake the pool tokens against the asset pool 422 by adding or assigning them in the staking rewards contract (and thus the farm 428). In this case, value is distributed as follows: the rewards contract receives reward tokens issued based on the performance of the asset pool 422 and the asset provider 412 becomes entitled to a proportional share of the reward tokens.

The farming system may execute predetermined metrics, such as performance and weight metrics, to track performance and update weights, as described further below. The decentralized and self-sustaining configuration of the yield farming system, according to some examples, allows a value distribution process or protocol to continue operating as intended automatically and without requiring manual (e.g., developer) intervention, while ensuring that the criteria used for aspects such as selecting eligible pools and distributing rewards is strictly adhered to.

Referring now to FIG. 5, a method 500 is shown for deploying self-executing contracts to a blockchain network to register, track the performance of, and/or distribute value to asset pools of a DeFi protocol, according to some examples. By way of example and not limitation, aspects of the method 500 may be performed by the self-executing contracts, modules, components, systems, or devices shown in FIGS. 1-4. Accordingly, while reference is made to some of these self-executing contracts, modules, components, systems, or devices below, it will be appreciated that at least some operations of FIG. 5 may also be performed by other self-executing contracts, modules, components, systems, or devices.

Again, while the method 500 of FIG. 5 is described with reference to the issuing of rewards in the form of tokens, it will be appreciated that similar contracts or techniques may be employed for other types of value distribution, such as interest payments, asset allocations, fees, dividends, cash, airdrops to wallet addresses, NFT rewards, or the like.

The method 500 commences at opening loop element 502, and proceeds to operation 504, where a plurality of self-executing contracts, e.g., the self-executing contracts 302 of FIG. 3, are deployed to a blockchain network, e.g., the blockchain network 236 of FIG. 2. As mentioned, the internal contracts 304 may be used to integrate a yield farming system with a DeFi protocol, e.g., an asset management protocol. For example, the DeFi protocol may run the asset pools 422, 424, 426 shown in FIG. 4 and the yield farming system may be “plugged in” to the DeFi protocol as described above. In other examples, the operation 504 may involve deploying self-executing contracts governing both the underlying DeFi protocol and its farming or value distribution system.

At operation 506, the asset pools 422, 424, 426 are registered with the yield farming system, e.g., using the pool manager contract 306. Responsive to registration, the staking rewards factory contract 308 generates a staking rewards contract 310 for each of the asset pools 422, 424, 426 to generate the farms 428, 430, 432. Users, e.g., asset providers, are able to stake pool tokens against associated asset pools, and the yield farming system receives, through each relevant staking rewards contract 310, an indication of the staking of pool tokens (operation 508).

At operation 510, the staking rewards contract 310 for each asset pool generates staking data. The staking data may be stored on the blockchain network 236, e.g., in the respective farms 428, 430, 432, to indicate each user's stake or share in rewards issued to the relevant asset pool. The staking rewards contract 310 may continuously update the staking data over time. When a user executes a transaction to redeem rewards, the staking data is used to determine the rewards to which the user is entitled.

As mentioned, the yield farming system tracks the performance of the asset pools. Specifically, in some examples, the performance of a particular registered asset pool is tracked relative to the performance of other registered asset pools using a sliding time window and a predetermined performance metric (operation 512).

In some examples, performance tracking is effected through global state variables in the pool manager contract 306. For example, a variable of type “mapping (pool address=>mapping (period index=>price)” can store each pool's price for each period index. Similar variables may be used to store other information for each pool, such as weight, duration, APC, or the like. These variables may be updated whenever an update weight function, such as “PoolManager.updateWeight()” is called.

Using sliding time periods, e.g., starting from the time when the system was deployed, can improve tracking of pool performance over time and help prevent malicious actors. For example, the use of sliding (e.g., forward-moving) periods can filter out inactive asset pools. The yield farming system may, in some examples, utilize a sliding time window of a predetermined duration to track asset pool performance. For example, the sliding time window may be a 14-day period. The sliding time window may be used together with another, previous “sliding” time period to enable a comparison with past performance, as described below.

In some examples, the sliding time window referred to above is a second period in which a state of the asset pool was updated, and the predetermined performance metric tracks the performance of the asset pool by comparing the performance of the asset pool in the second period to the performance of the asset pool in a first period (prior to the second period) in which the state of the asset pool was also updated. Both the first period and the second period may have a predetermined duration, e.g., both may be a 14-day period.

In some examples, the second period is a “latest recorded period” and the first period is a “previous recorded period.” The latest recorded period refers to the most recent period in which the pool was updated. The pool may be deemed “updated” if a predetermined transaction is performed against the pool (or affecting the pool in some way). The previous recorded period refers to the most recent period prior to the latest recorded period in which the pool was updated. In cases where an asset pool has only been updated in one period, the first period and the second period may be the same period.

Accordingly, in some cases, the yield farming system implemented by the self-executing contracts 302 keeps track of two discrete periods for each registered asset pool. A pool period index can be calculated using the formula below, in which i is pool period index, t_c is current time, t_s is starting time, and d is the period duration. This formula may be incorporated into one of the self-executing contracts 302.

i=(t_c−t_s)/d

The starting timestamp of a period can be calculated using the formula below, in which t_i is the starting timestamp of period “i” and the other symbols bear the same meanings as in the pool period index formula above. This formula may be incorporated into one of the self-executing contracts 302.

t_i=t_s+(i*d)

The use of discrete and moving pool periods when calculating pool performance and pool weight may allow pools that outperform over recent periods to receive value (e.g., rewards) regardless of their longer-term performance, e.g., lifetime performance. Further, the sliding pool periods may ensure that brief periods of outperformance “fade away” over time, incentivizing consistent outperformance.

In some examples, the predetermined performance metric comprises an Average Price Change (APC) metric. In such cases, performance of the asset pool is tracked by determining an APC associated with the asset pool between the first period to the second period. The formula below illustrates how APC can be calculated for an asset pool to compare percentage change in pool token price (which is used downstream when calculating pool weight), according to some examples. In the formula below, APC tracks the current pool token price in the current period (e.g., the second period referred to above) versus the last recorded pool token price in the latest period before the current period in which the pool was updated (e.g., the first period referred to above). In the formula, p is the current pool token price in the current period, p_i is the last recorded pool token price in the latest period before the current period, t is the index of the current period, and t_i is the index of the latest period before the current period. This formula may be incorporated into one of the self-executing contracts 302, e.g., the pool manager contract 306.

$\mathrm{APC}=\frac{1000*\left(p-p_i\right)}{p_i*\max \left(1,t-t_i\right)}$

It will be noted that APC is scaled by a factor of 1000 to preserve fractional percent changes, since, at least in some examples, fractional values may not be allowed in self-executing contracts. For example, a 100% price increase over two periods would result in an APC of 1000, and a 0.1% price increase over two periods would result in an APC of 1. The “max” function is used to account for the edge case where t=t_i when the current period is the first period, which would lead to division by zero. In this case, the value is hard-coded to one.

It is noted that, in some examples, the index of the first period is not necessarily the index immediately preceding the index of the second period. For instance, if the current period is at index 5 and the asset pool was last updated in period 1, then the first period index would be 1 (and not 4). In this way, the farming system may account for inactivity between two periods while ensuring that a pool's change in token price can be calculated.

In some examples, the use of APC may be preferable to techniques such as lifetime return. For example, when using lifetime return, the weight of a pool (as described further below) may remain at zero until there is a positive lifetime return. This may result in technical challenges, e.g., during an unfavorable market, rendering the farming system inoperable or ineffective. Furthermore, using APC may prevent asset pools with relatively inflated lifetime returns (which may result from an excessive risk that paid off) from monopolizing global weight for more than a limited period, e.g., the two periods described above.

Prior to updating the weight of an asset pool, the yield farming system may update the available rewards associated with the asset pool and withdraw unlocked (e.g., released) reward tokens from the release escrow contract 314 (shown in FIG. 3). Unlocked reward tokens may be withdrawn on behalf of all asset pools registered in the yield farming system. The example algorithm entitled “Algorithm 1” below provides a non-limiting example of an algorithm that may be automatically implemented, e.g., by the pool manager contract 306, to update the rewards of an asset pool.

Example Algorithm 1: Updating a Pool's Rewards

1: r0 ← r
2: r ← rewardPerToken( )
3: if r0 = r and releaseEscrow.hasStarted( ) then
4: Transfer unlocked tokens from the ReleaseEscrow contract to the
   PoolManager contract
5: Transfer unlocked tokens from the PoolManager contract to the
   dedicated recipient
6: end if
7: lastUpdateTime ← currentTime
8: rewards[pool] ← earned(pool)
9: poolRewardPerTokenStored[pool] ← r

In Algorithm 1, operation 2 calculates a new global reward per token stored based on a current global scaled weight (described below) and the available rewards in the release schedule. Operation 3 compares the initial global reward per token stored to the new global reward per token stored to check whether the current global scaled weight is zero. If this occurs after the release schedule has started, then the unlocked reward tokens may be sent to a dedicated recipient, e.g., to avoid getting lost, since asset pools may not earn rewards when the total weight is zero. Operation 8 updates the accumulated rewards of the asset pool to ensure that they do not decrease when the weight of the pool is subsequently changed. Operation 9 sets the reward per token stored of the asset pool to the global reward per token stored such that the asset pool has zero pending rewards. This may be performed to prevent “double counting,” e.g., since any additional rewards earned since a last update would already be accounted for in operation 8.

Turning now to the updating of the weight of the asset pool, as mentioned, in some examples, the weight of the asset pool is updated by assessing performance relative to other asset pools (operation 514). The predetermined weight metric may determine the weight of the asset pool based on the APC associated with the asset pool relative to an APC associated with a group of asset pools, as described further below. In some examples, the weight of a pool may be updated each time a specific transaction occurs. For example, when a predetermined transaction is performed, the DeFi protocol may pass relevant data (e.g., total value of the asset pool and performance of the asset pool) into a weight updating function of the pool manager contract 306.

The formula below shows how the weight of a pool may be determined, according to some examples. The formula below is intended to make all pools with positive weight eligible for rewards, while allocating more rewards to outperforming pools. More specifically, the weight of an asset pool is based on the APC of the pool (as described above) relative to an average APC across all rewards-eligible pools registered with the yield farming system. All pools with an APC that is greater than zero (e.g., any amount of unrealized profits over the second period or the first period) has a positive weight and will thus be value distribution-eligible, e.g., eligible for rewards. Pools performing below average will still have a positive weight, but the weight is lower than it would be if the same pool's performance were above average. In the formula below, p is the pool's unrealized profits, APC is as defined above for the particular asset pool, and aAPC is the average APC across all pools in the farming system that meet the relevant minimum criteria. This formula may be incorporated into one of the self-executing contracts 302, e.g., the pool manager contract 306. In this context, the term “unrealized profits” refers to the current value (e.g., dollar value) of the pool minus the total value (e.g., dollar value) of user deposits into the pool. The value of user deposits acts as a “cost basis,” and is calculated at the time of deposit and does not change with fluctuations in asset price.

$w=\left\{\begin{array}{cc}p*\sqrt{\mathrm{APC}-\mathrm{aAPC}+1},& \mathrm{if}\mathrm{APC}\ge \mathrm{aPC}\\ \frac{p*{\log }_2\mathrm{APC}}{\sqrt{\mathrm{aAPC}-\mathrm{APC}}},& \mathrm{if}\mathrm{APC}<\mathrm{aAPC}\end{array}\right\}$

In some examples, the average APC is calculated using the formula below, in which APC is the APC of pool i and n is the number of eligible pools in the farming system. This formula may be incorporated into one of the self-executing contracts 302, e.g., the pool manager contract 306.

$\mathrm{aAPC}=\frac{{\sum }_i^n{\mathrm{APC}}_i}{n}$

The example algorithm entitled “Algorithm 2” below provides a non-limiting example of an algorithm that may be automatically implemented, e.g., by the pool manager contract 306, to update the weight of the asset pool. The example Algorithm 2 references Algorithm 1 described above as well as Algorithm 3, which will be described below. In some examples, the weight of an asset pool is updated responsive to detecting updating of the state of the asset pool (e.g., the state may be updated by execution of a predetermined transaction against the asset pool, such as depositing, withdrawing, exchanging, or taking a pool snapshot).

Example Algorithm 2: Updating a Pool's Weight

1:  Use Algorithm 1
2:  if u < 0 or p ≤ 0 then
3:  Throw error
4:  end if
5:  w0 ← w[pool, i]
6:  if currentperiodindex > poolslatestrecordedperiodindex then
7:  previous RecordedPricepool ← latestRecordedPricepool
8:  previousRecordedPeriodIndexpool ←
    latestRecordedPeriodIndexpool
9:  end if
10: upool ← u
11: latestRecordPricepool ← p
12: latestRecordedPeriodIndexpool ← i
13: if pool is not eligible then
14: lastUpdatedpool ← currentTime
15: Return early
16: end if
17: Subtract from totalWeightedAPC and totalDuration
18: APCpool ← calculateAveragePriceChange(pool)
19: lastUpdatedpool ← currentTime
20: Add to totalWeightedAPC and totalDuration
21: w ← calculatePoolWeight(pool)
22: poolPeriods[pool, i] ← w
23: globalPeriodsi ← globalPeriodsi − w0 + w
24: Use Algorithm 3

In Algorithm 2, Operation 1 calls Algorithm 1 to update the pool's rewards. Operations 2-4 revert the transaction if the pool has an unrealized loss (u) or the pool's token price (p) is below 0. These values are provided by the external protocol when calling the function “PoolManager.updateWeight( )” Operation 5 creates a temporary variable that stores the pool's weight for the current period (before updating). Operations 6-9 set the pool's “previous recorded price/index” to the “latest recorded price/index” if the current period index (global) is greater than the pool's “latest recorded period index.” This is done to keep track of the two periods needed for calculating APC. Operation 10 sets the pool's unrealized profits to the unrealized profits provided by the external protocol. Operation 11 sets the pool's latest recorded price to the pool token price provided by the external protocol. Operation 12 sets the pool's “latest recorded period index” to the current global period index. Operations 13-16 set the pool's “last updated” timestamp to the current timestamp and ends the algorithm early if the pool is not eligible for rewards. Operation 17 subtracts the pool's time-scaled APC and duration from the “totalWeightedAPC” and “totalDuration” global variables before updating the pool's APC and “last updated” timestamp. Operation 18 sets the pool's APC to the value calculated using the example formula provided above. Operation 19 sets the pool's “last updated” timestamp to the current timestamp (global). Operation 20 adds the pool's new APC and duration (number of seconds the pool has existed) to the “totalWeightedAPC” and “totalDuration” global variables. Operation 21 creates a temporary variable (w) that stores the pool weight calculated using the example formula provided above. Operation 22 sets the pool weight for the current period to the value calculated in Operation 21. Operation 23 updates the global weight for the current period by the difference between the value calculated in Operation 21 and the value calculated in Operation 5. Operation 24 uses Algorithm 3 to get the latest rewards.

As mentioned, updating weights may be carried out using Algorithm 2, and such an algorithm may be implemented on a self-executing contract, such as an Ethereum Virtual Machine (EVM) “smart contract.”

It is noted that, in some examples, such as in the case of an EVM blockchain, the code stored in a self-executing contract is immutable and is guaranteed to execute as described in the deployed bytecode whenever a transaction is sent to the contract.

Still referring to the method 500 of FIG. 5, the method 500 includes distributing value to the asset pool based on the weight of the asset pool at operation 516. In this example, and as mentioned above, value distribution involves issue reward tokens based on the weight of the asset pool. The method 500 may include detecting updating of a state of the asset pool (e.g., a transaction performed with respect to the asset pool), detecting that the asset pool is value distribution-eligible, and responsive to detecting the updating of the state of the asset pool and that the asset pool is value distribution-eligible, distributing value by issuing the rewards to the asset pool.

In some examples, to determine the rewards to which a particular asset pool is entitled, the asset pool's share of global rewards must be determined. A pool's share of available rewards may be calculated by taking the ratio of the pool's weight in the current period to global weight in the current period. In some examples, to prevent weights from starting at zero whenever a new period starts, linear time scaling is applied to weights in the current period (e.g., the second period referred to above) and the previous period (e.g., the first period referred to above). The time-scaled weight may be calculated using the formula below, in which w, represents the time-scaled weight, w represents the weight in the current period, wo represents the weight in the previous period, t represents the current time, to represents the start time for the current period, and d represents the period duration. This formula may be incorporated into one of the self-executing contracts 302, e.g., the pool manager contract 306.

$w_c=\frac{\left[w*\left(t-t_0\right)\right]+\left[w_0*\left(d+t_0-t\right)\right]}{d}$

There may be an edge case where time-scaled weights are strictly lower in the first period of the farming system, since the weights for the previous period would be zero by default, but both pool and global weights would be multiplied by the same scalar, so the reward distribution is not affected. In some examples, time scaling also penalizes pools that were inactive or underperforming in either the current period or previous period without eliminating their share of rewards entirely. Their rewards are reduced based on the time elapsed in the underperforming period versus the time elapsed in the other period.

A current global scaled weight may be calculated using the formula above for time-scaled weight by using w as the global weight in the current period (e.g., the second period referred to above), wo as the global weight in the previous period (e.g., the first period referred to above), t as the current timestamp, and t₀ as the starting timestamp for the current period. After calculating the global scaled weight, the current global reward per token (r) can be calculated using the formula below, in which r₀ is the current global reward per token stored, x is the number of tokens unlocked in the release schedule, and w is the global scaled weight calculated previously. This formula may be incorporated into one of the self-executing contracts 302, e.g., the pool manager contract 306.

$r=\left\{\begin{array}{cc}{r}_0+\frac{x}{w},& \mathrm{if}w>0\\ r_0,& \mathrm{if}w=0\end{array}\right\}$

In some examples, after calculating the global reward per token stored and the global scaled weight, the relevant asset pool's scaled weight may be calculated using the above formula with the weight of the asset pool in the current period for w and the weight of the asset pool in the previous period for wo. When calculating the scaled weight of an asset pool and global scaled weight, wo can be set to zero in the case of the first period since the release escrow started.

The share of rewards for the particular asset pool may then be calculated using the formula below, in which x is the number of tokens unlocked for the pool, w is the pool's scaled weight, r is the reward per token calculated previously, r_pool is the reward per token when the pool last claimed rewards, and x₀ is the number of tokens accumulated when the pool last updated its weight. It is noted here that both the scaled pool weight and the scaled global weight are multiplied by the same scalar, and the global weight changes by delta w_pool whenever a pool is updated, resulting in the sum of pool weights equaling the global weight. The formula below may be incorporated into one of the self-executing contracts 302, e.g., the pool manager contract 306.

x=(w*(r−r_pool))+x₀

At operation 516 of the method 500, rewards are issued to the relevant asset pool. The example algorithm entitled “Algorithm 3” below provides a non-limiting example of an algorithm that may be automatically implemented, e.g., by the pool manager contract 306, to transfer pending rewards to the farm of a pool, e.g., the farm 428 of the asset pool 422 of FIG. 4. The operations below may be triggered by the staking rewards contract 310 of the farm 428 in response to a user claiming rewards.

Example Algorithm 3: Getting Rewards

1:  Update the pool's rewards
2:  Withdraw unlocked tokens from the ReleaseEscrow contract and
    store them in the PoolManager contract
3:  x ← xpool
4:  if x > 0 then
5:  xpool ← 0
6:  Transfer x tokens to the pool's farm
7:  if the farm's total supply = 0 then
8:  Transfer pool's share of tokens to the dedicated recipient
9:  end if
10: rfarm ← rfarm + x/sfarm
11: end if

In Algorithm 3, Operation 1 uses Algorithm 1 to update the pool's rewards. Operation 2 calculates the protocol's pending rewards based on the halving schedule in the release escrow contract 314 and the elapsed time since the last claim, withdraws the calculated number of tokens from the release escrow contract 314, and transfers the tokens to the pool manager contract 306. Operation 3 creates a temporary variable (x) with value set to the pool's stored rewards. This is done to keep track of the distributed reward after the stored rewards have been reset to 0. Operation 5 resets the pool's stored rewards to 0. Operations 7-9 handle the edge case where the farm has no pool tokens deposited. In this case, rewards are transferred to the dedicated recipient (staking contract or any address the protocol owner chooses) instead of the farm. This may prevent tokens from getting “stuck” in the contract. Operation 10 updates the farm's “reward per token stored.” The symbol s_farm represents the farm's total supply of tokens deposited. At operation 518, value can then be allocated, distributed, or transferred to a user (e.g., the asset provider 412). In this case, the user is provided with rewards based on the staking data of the asset pool. The method 500 ends at closing loop element 520.

As mentioned above, various types of value distribution criteria may be employed, depending on the implementation or use case. Generally, if it were too “easy” to register an asset pool and become eligible for value distribution, users may be more likely to take excessive risks in an attempt to obtain a higher pool weight. Excessive risk-taking may be detrimental to investors since it may be more likely to have negative expected value.

Further, robust value distribution criteria may reduce the risk of a successful “Sybil attack” where a user, for example, creates multiple accounts to interact with a DeFi protocol with malicious intent. In the context of a yield farming system, a Sybil attack could involve the creation of multiple wallets to bypass the pool-per-user limit on a DeFi protocol integrating the farming system. A user may take on excessive risks on each of their pools in the hope that risk will generate large returns for one of the pools. The pool with a large return may then have a greater weight in the farming system, leading to a higher Annual Percentage Rate (APR) for the pool's farm, which would incentivize other users to invest in the pool, e.g., simply to deposit the pool tokens in the pool's farm. To help discourage excessive risk-taking and reduce the possibility of a Sybil attack, as well as the potential damage to a DeFi protocol if a Sybil attack is conducted, the farming system may introduce one or more minimum value distribution criteria that an asset pool must meet before it can be eligible for value distribution.

For example, and as mentioned above, the following value distribution criteria may be used:

A. Pool has existed for at least a predetermined number of days, e.g., 30 days;
B. Pool has at least a predetermined number of unique asset providers/investors, e.g., 10 unique investors; or
C. Pool has at least a minimum asset value, e.g., $1000 in value.

In some examples, criterium A encourages pool managers to establish a track record to prove that they are consistently performing well. By having a track record of consistent outperformance, pool managers can demonstrate to potential investors that their strategy has positive expected value. It may still be possible for pool managers to take excessive risk and wait, for example, for 30 days without making additional trades to maintain an artificially high lifetime return, but the profitable trade will not impact the pool's weight after two periods based on the sliding system described above. In some examples, criteria B and C in combination could help to discourage Sybil attacks. A user wanting to bypass these requirements would need to deposit at least the minimum value (e.g., $1000) of their own funds across multiple accounts to simulate multiple unique investors. It may be unlikely that extra rewards from having a higher pool weight would outweigh the invested value at risk.

Turning to FIG. 6, a method 600 is shown to facilitate user interaction with an asset pool of a DeFi protocol, according to some examples. By way of example and not limitation, aspects of the method 600 may be performed by the self-executing contracts, modules, components, systems, or devices shown in FIGS. 1-4. Accordingly, while reference is made to some of these self-executing contracts, modules, components, systems, or devices below, it will be appreciated that at least some operations of FIG. 6 may also be performed by other self-executing contracts, modules, components, systems, or devices.

Again, while the method 600 of FIG. 6 is described with reference to the issuing of rewards in the form of tokens, it will be appreciated that similar contracts or techniques may be employed for other types of value distribution, such as interest payments, asset allocations, fees, dividends, cash, airdrops to wallet addresses, NFT rewards, or the like.

The method 600 commences at opening loop element 602, and proceeds to operation 604, where the interface system 226 of FIG. 2 receives a request for a user account. For example, the user 208 may use the app interface 234 to request, via the user device 206, a user account with the interface system 226. The user account may be a DeFi application account. The interface system 226 then generates an account for the user 208 and stores a record of the account in the database 230 (operation 606).

At operation 608, the interface system 226 receives an asset pool instruction from the user device 206 of the user 208. For example, the user 208 may be the asset provider 412 of FIG. 4 requesting to invest in the asset pool 422 and/or to stake pool tokens in the farm 428 associated with the asset pool 422. At operation 610, the user 208 is associated with the asset pool 422 automatically on the blockchain network 236, e.g., through operation of the pool manager contract 306 or the staking rewards contract 310 of FIG. 3. Further, the interface system 226 may associate the user 208 with the asset pool 422 in the record stored in the database 230.

At operation 612, the interface system 226 tracks performance of the asset pool 422 on the blockchain network 236. For example, the interface system 226 may monitor the APC and the weight of the asset pool 422 and/or the value distributed to the asset pool 422.

In this way, the interface system 226 can conveniently provide the user 208 with information regarding the asset pool 422 or value (e.g., rewards) available to the user 208. At operation 614, the interface system 226 may transmit a message to the user device 206 (e.g., via the app interface 234) to notify the user device 206 of value distribution, such as rewards issued or allocated to the asset pool 422, or a specific share of the rewards that the user 208 is entitled to claim.

The user 208 may then utilize the user device 206 to transmit a claim (e.g., reward claim), and the interface system 226 may receive a notification of the claim or the intention to claim a reward (operation 616). As explained, while a reward is claimed directly on the blockchain network 236, the interface system 226 may abstract away some of the technical aspects of claiming a reward, e.g., by facilitating the transaction through the app interface 234 (operation 618). The method 600 concludes at closing loop element 620.

A reward can be claimed from a farm, e.g., from the farm 428 associated with the asset pool 422 of FIG. 4, by interacting with one or more of the self-executing contracts 302 deployed to the blockchain network 236. The example algorithm entitled “Algorithm 4” below provides a non-limiting example of an algorithm that may be automatically implemented on the blockchain network 236, e.g., responsive to a claim, to ensure that reward tokens are transferred to the user 208. For example, assuming that the user 208 is the asset provider 412 and has pool tokens staked in the farm 428 of FIG. 4, the user 208 can initiate the claim by calling a “claiming” function of the relevant staking rewards contract 310.

Example Algorithm 4: Claiming Rewards From a Farm

1:  if pool is not marked as eligible then
2:  Throw error
3:  end if
4:  Withdraw unlocked tokens from the ReleaseEscrow contract on
    behalf of all pools
5:  Transfer the pool's share of tokens to the pool's farm
6:  if the farm's total supply = 0 then
7:  Transfer pool's share of tokens to the dedicated recipient
8:  end if
9:  rfarm ← rfarm + x/sfarm
10: xuser ← earned(user)
11: ruser < rfarm
12: Transfer xuser tokens to the user
13: xuser ← 0

In Algorithm 4, Operations 1-3 revert the transaction if the pool is not eligible for rewards. Operation 4 withdraws all pending tokens for the system from the release escrow contract 314 (according to the halving schedule) and stores them in the pool manager contract 306. This keeps the release escrow contract 314 agnostic to the pools. Operation 5 calculates the pool's share of tokens and transfers them to the farm. The pool's pending rewards is set to 0 in the process. Operations 6-8 handle the edge case where a pool receives rewards, but no one has deposited pool tokens into the pool's farm. In this case, the tokens that would have gone to the farm are instead transferred to the dedicated recipient to make sure all tokens are accounted for (tokens could get “stuck” in the pool manager contract 306 otherwise). The dedicated recipient may for example be a staking contract, a Decentralized Autonomous Organization (DAO), or any address the protocol owner selects when deploying the system. Operation 9 updates the farm's “reward per token stored.” In operation 10, x_user is the user's stored rewards, separate from the rewards calculated by the difference between “reward per token stored.” Setting this value to “earned(user)” ensures that updating both the global and user “reward per token stored” does not reduce the user's rewards. Operation 11 sets the user's “reward per token stored” to the farm's “reward per token stored.” Operation 12 sends the stored rewards to the user, and operation 13 clears the stored rewards to prevent double-counting.

Various strategies may be considered or implemented for addressing certain aspects of security. When it comes to malicious actors, two main categories may be identified in the context of an asset management protocol: (1) pool managers who use risky strategies across multiple pools in hopes of a high pool weight, and (2) pool managers who stay primarily in stablecoins to obtain a high pool weight with near-zero unrealized profits.

Referring to the first category, this may include a pool manager who uses a risky strategy across multiple pools by creating a new pool for each trade until a profitable trade is made. In this context, a “risky strategy” is defined as a strategy where the probability of achieving a profit target is small compared to the probability of hitting a stop loss. These strategies need to necessarily have negative expected value to be detrimental to a farming system, as long as there are more unprofitable trades than profitable ones. Pools with a losing trade will have a negative return on investment (ROI) for the current period, leading to zero weight. A pool with a profitable trade will have a positive ROI for the current period, leading to a positive weight and a share of the value distribution for the current period. Such strategies may possibly be detrimental to the farming system, because they may lead to a large number of inactive pools, making it challenging for potential investors to find reliable pools. In addition to crowding the DeFi protocol, these strategies may also reduce value distribution to reliable pools.

In some cases, a pool manager may be incentivized to use a risky strategy as long as the expected value of the profitable pool's farming rewards exceeds the total expected cost. The total expected cost of such a strategy is the total loss across unprofitable trades minus the profit from the one profitable trade. Before a profitable trade is made, n unprofitable trades may be expected, as shown below, where p is the probability of a profitable trade.

$n=\frac{1-p}{p}$

The total expected cost could then be calculated by using the formula below, in which c is the total expected cost, m is the minimum investment per pool (e.g., in accordance with the example minimum value distribution criteria above), p is the percentage loss on an unprofitable trade, and p₊ is the percentage profit on a profitable trade.

$c=m\left[p_{-}\left(\frac{1-p}{p}\right)-p_{+}\right]$

The pool's share of rewards is the monetary value of the total rewards distributed over the current period multiplied by the ratio of the pool's weight for the current period to the global weight for the period. The reward rate is defined as the monetary value of rewards distributed per second, and is given by the formula below, in which r is the reward rate, n is the lifetime number of reward tokens (e.g., protocol governance tokens) that will be distributed, v is the monetary value per token, i is the index of the cycle, n_p is the number of periods per cycle, and d_p is the duration of a period in seconds.

$r=\frac{\mathrm{nv}}{2^i{n}_p{d}_p}$

The total monetary value (R) distributed per period is given by the formula below, in which r is the reward rate and d_p is the duration of a period in seconds.

R=rd_p

Substituting the above formula for R into the above formula for r provides the following:

$R=\frac{\mathrm{nv}}{2^i{n}_p}$

In this context, a pool's share of rewards is given by the following formula, in which R_pool is the monetary share of rewards of the pool, w_pool is the weight of the pool for the current period, and W_global is the global weight for the current period.

$R_{\mathrm{pool}}=\frac{{\mathrm{Rw}}_{\mathrm{pool}}}{w_{\mathrm{global}}}$

Substituting the formula for R directly above with the formula for R_pool provides the following:

$R_{\mathrm{pool}}=\frac{{\mathrm{nvw}}_{\mathrm{pool}}}{2^i{n}_p{w}_{\mathrm{global}}}$

A Sybil attack may be considered profitable if R_pool is greater than c and this can be expressed as follows:

$\frac{{\mathrm{nvw}}_{\mathrm{pool}}}{2^i{\mathrm{mn}}_p{w}_{\mathrm{global}}\left[p_{-}\left(\frac{1-p}{p}\right)-p_{+}\right]}>1$

From the above inequality, it is noted that the probability of a successful attack decreases after each cycle as long as the increase in scarcity causes the token price to increase by a factor less than two. In some examples, as more pools register with the farming system, the weight of an attacker's profitable pool will constitute a progressively smaller portion of the total weight, decreasing the profitability of an attack.

Referring now to the second category of malicious actors, this includes pool managers who stay primarily in stablecoins and only trade a small fraction of the pool's funds to maintain a non-zero pool weight. These pool managers may not be detrimental to investors, but may affect the nature of a DeFi protocol integrating the farming system, e.g., by transforming it into a stablecoin farming protocol if many registered pools use such a strategy.

In some cases, pools may generally be encouraged to stay invested in appreciating assets to remain competitive, but during an unfavorable market, for example, pools may be more likely to have a negative ROI by staying invested in assets than by staying invested in stablecoins. Under such conditions, pool managers may opt to keep the majority of pool funds in stablecoins and only trade a small fraction of the funds to have non-zero unrealized profits (thus earning value, e.g., rewards, for the pool). As a new favorable market emerges, pools trading assets other than stablecoins may then outperform pools staying in stablecoins, which may cause a migration of investors from stablecoin pools. The weight of asset pools may increase as they receive more investments, leading to higher value distribution. Accordingly, this design may mitigate the second category as stablecoin pools may start trading assets to remain competitive.

Four so-called “edge cases” are discussed below from a value distribution perspective, with reference to examples in Table 1. The edge cases are listed below:

A. Zero eligible asset pools;
B. One eligible asset pool with a loss;
C. One eligible asset pool with a non-zero predetermined weight and $10,000 invested; and
D. Multiple eligible pools with non-zero weights.

Calculations are made using the formulas described herein and, for simplicity, the calculations are made with a token price of $0.01 and a weekly value distribution in the form of rewards of 1 million reward tokens.

TABLE 1
Summary of four example edge cases
			Unrealized		Tokens
Pool	TVL	APC	Profits	Weight	per Week	APR
A	$10000	200	$1000	666.67	3412.40	17.74%
B	$15000	400	$300	2700	13820.16	47.91%
C	$300000	200	$45000	30000	153557.41	26.61%
D	$1200000	400	$18000	162000	829210.01	35.93%

In case A, since there are no eligible pools (global scaled weight is zero), 1 million reward tokens go to the farming system's dedicated recipient (e.g., a staking contract for the reward token). In case B, the global scaled weight is zero, because the only eligible pool in the farming system has zero unrealized profits. As in case A, the reward tokens will go to the dedicated recipient.

In case C, the pool will receive $10,000 worth of reward tokens per week, for an APR of 5200%. The excessive APR will either cause the reward token price to fall or lead to an influx of investments into the pool until the APR drops. In case D, pools have varying weights, but similar APR despite having different TVLs (Total Value Locked). The APR for outperforming pools is higher. It is noted that the unrealized profits are lower than expected for the given TVL, since users are depositing into the pools at different times. As explained above, in some examples, a pool's weight is directly proportional to its unrealized profits. Since the increase in weight from higher unrealized profits equals a decrease in a user's portion of the pool's rewards, a pool's APR is unaffected by an increase in deposits.

FIG. 7 is a block diagram 700 showing a software architecture 702 for a computing device, according to some examples. The software architecture 702 may be used in conjunction with various hardware architectures, for example, as described herein. FIG. 7 is merely a non-limiting illustration of a software architecture, and many other architectures may be implemented to facilitate the functionality described herein. A representative hardware layer 704 is illustrated and can represent, for example, any of the above referenced computing devices. In some examples, the hardware layer 704 may be implemented according to the architecture of the computer system of FIG. 8.

The representative hardware layer 704 comprises one or more processing units 706 having associated executable instructions 708. Executable instructions 708 represent the executable instructions of the software architecture 702, including implementation of the methods, modules, subsystems, and components, and so forth described herein and may also include memory and/or storage modules 710, which also have executable instructions 708. Hardware layer 704 may also comprise other hardware as indicated by other hardware 712 and other hardware 722 which represent any other hardware of the hardware layer 704, such as the other hardware illustrated as part of the software architecture 702.

In the architecture of FIG. 7, the software architecture 702 may be conceptualized as a stack of layers where each layer provides particular functionality. For example, the software architecture 702 may include layers such as an operating system 714, libraries 716, frameworks/middleware layer 718, applications 720, and presentation layer 744. Operationally, the applications 720 or other components within the layers may invoke API calls 724 through the software stack and access a response, returned values, and so forth illustrated as messages 726 in response to the API calls 724. The layers illustrated are representative in nature and not all software architectures have all layers. For example, some mobile or special purpose operating systems may not provide a frameworks/middleware layer 718, while others may provide such a layer. Other software architectures may include additional or different layers.

The operating system 714 may manage hardware resources and provide common services. The operating system 714 may include, for example, a kernel 728, services 730, and drivers 732. The kernel 728 may act as an abstraction layer between the hardware and the other software layers. For example, the kernel 728 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. The services 730 may provide other common services for the other software layers. In some examples, the services 730 include an interrupt service. The interrupt service may detect the receipt of an interrupt and, in response, cause the software architecture 702 to pause its current processing and execute an interrupt service routine (ISR) when an interrupt is accessed.

The drivers 732 may be responsible for controlling or interfacing with the underlying hardware. For instance, the drivers 732 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, near-field communication (NFC) drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration.

The libraries 716 may provide a common infrastructure that may be utilized by the applications 720 or other components or layers. The libraries 716 typically provide functionality that allows other software modules to perform tasks in an easier fashion than to interface directly with the underlying operating system 714 functionality (e.g., kernel 728, services 730 or drivers 732). The libraries 716 may include system libraries 734 (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries 716 may include API libraries 736 such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGL framework that may be used to render two-dimensional and three-dimensional in a graphic content on a display), database libraries (e.g., SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. The libraries 716 may also include a wide variety of other libraries 738 to provide many other APIs to the applications 720 and other software components/modules.

The frameworks/middleware layer 718 may provide a higher-level common infrastructure that may be utilized by the applications 720 or other software components/modules. For example, the frameworks/middleware layer 718 may provide various graphic user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware layer 718 may provide a broad spectrum of other APIs that may be utilized by the applications 720 or other software components/modules, some of which may be specific to a particular operating system or platform.

The applications 720 include built-in applications 740 or third-party applications 742. Examples of representative built-in applications 740 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, or a game application. Third-party applications 742 may include any of the built-in applications as well as a broad assortment of other applications. In a specific example, the third-party application 742 (e.g., an application developed using the Android™ or iOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as iOS™, Android™, Windows® Phone, or other mobile computing device operating systems. In this example, the third-party application 742 may invoke the API calls 724 provided by the mobile operating system such as operating system 714 to facilitate functionality described herein.

The applications 720 may utilize built in operating system functions (e.g., kernel 728, services 730 or drivers 732), libraries (e.g., system libraries 734, API libraries 736, and other libraries 738), and frameworks/middleware layer 718 to create user interfaces to interact with users of the system. Alternatively, or additionally, in some systems, interactions with a user may occur through a presentation layer, such as presentation layer 744. In these systems, the application/module “logic” can be separated from the aspects of the application/module that interact with a user.

Some software architectures utilize virtual machines. In the example of FIG. 7, this is illustrated by virtual machine 748. A virtual machine creates a software environment where applications/modules can execute as if they were executing on a hardware computing device. A virtual machine is hosted by a host operating system (operating system 714) and typically, although not always, has a virtual machine monitor 746, which manages the operation of the virtual machine as well as the interface with the host operating system (e.g., operating system 714). A software architecture executes within the virtual machine 748 such as an operating system 750, libraries 752, frameworks/middleware 754, applications 756 or presentation layer 758. These layers of software architecture executing within the virtual machine 748 can be the same as corresponding layers previously described or may be different.

Certain examples are described herein as including logic or a number of components, modules, or mechanisms. Components or modules may constitute either software components (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented components. A hardware-implemented component or hardware-implemented module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In examples, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more hardware processors may be configured by software (e.g., an application or application portion) as a hardware-implemented component or module that operates to perform certain operations as described herein.

In various examples, a hardware-implemented component may be implemented mechanically or electronically. For example, a hardware-implemented component may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented component may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or another programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented component mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Accordingly, the term “hardware-implemented module” or “hardware-implemented component” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering examples in which hardware-implemented modules/components are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules/components comprise, a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware-implemented modules/components at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware-implemented module/component at one instance of time and to constitute a different hardware-implemented module/component at a different instance of time.

Hardware-implemented modules/components can provide information to, and receive information from, other hardware-implemented modules/components. Accordingly, the described hardware-implemented modules/components may be regarded as being communicatively coupled. Where multiple of such hardware-implemented modules/components exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses that connect the hardware-implemented modules/components). In examples in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules/components have access. For example, one hardware-implemented module/component may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module/component may then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules/components may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules/components that operate to perform one or more operations or functions. The modules referred to herein may, in some examples, comprise processor-implemented modules/components.

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules/components. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some examples, the processor or processors may be located in a single location (e.g., within a home environment, an office environment, or a server farm), while in other examples the processors may be distributed across a number of locations.

The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service (SaaS).” For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).

Examples may be implemented in digital electronic circuitry, or in computer hardware, firmware, or software, or in combinations of them. Examples may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.

A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a standalone program or as a component, module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

In examples, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of some examples may be implemented as, special purpose logic circuitry, e.g., an FPGA or an ASIC.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In examples deploying a programmable computing system, it will be appreciated that both hardware and software architectures merit consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or in a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various examples.

FIG. 8 is a block diagram of a machine in the example form of a computer system 800 within which instructions 824 may be executed for causing the machine to perform one or more of the methodologies discussed herein. In alternative examples, the machine operates as a standalone computing device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a network router, switch, or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines (e.g., computing devices) that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system 800 includes a processor 802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 804, and a static memory 806, which communicate with each other via a bus 808. The computer system 800 may further include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 800 also includes an alphanumeric input device 812 (e.g., a keyboard or a touch-sensitive display screen), a user interface navigation (or cursor control) device 814 (e.g., a mouse), a storage unit 816, a signal generation device 818 (e.g., a speaker), and a network interface device 820.

The storage unit 816 includes a machine-readable medium 822 on which is stored one or more sets of data structures and instructions 824 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 824 may also reside, completely or at least partially, within the main memory 804 or within the processor 802 during execution thereof by the computer system 800, with the main memory 804 and the processor 802 also each constituting a machine-readable medium 822.

While the machine-readable medium 822 is shown in accordance with some examples to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that store the one or more instructions 824 or data structures. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding, or carrying instructions 824 for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions 824. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of a machine-readable medium 822 include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and compact disc read-only memory (CD-ROM) and digital versatile disc read-only memory (DVD-ROM) disks. A machine-readable medium is not a transmission medium.

The instructions 824 may further be transmitted or received over a communications network 826 using a transmission medium. The instructions 824 may be transmitted using the network interface device 820 and any one of a number of well-known transfer protocols (e.g., hypertext transport protocol (HTTP)). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Wi-Fi and Wi-Max networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions 824 for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

In view of the above-described implementations of subject matter this application discloses the following list of examples, wherein one feature of an example in isolation, or more than one feature of an example taken in combination, and, optionally, in combination with one or more features of one or more further examples, are further examples also falling within the disclosure of this application.

Example 1 is a system comprising: at least one memory component that stores instructions; and one or more processors configured by the instructions to perform operations comprising: causing one or more self-executing contracts deployed on a blockchain network to: associate an asset pool with a plurality of asset providers, one or more of the plurality of asset providers staking pool tokens against the asset pool, track performance of the asset pool in a sliding time window by applying a predetermined performance metric, update a weight of the asset pool by applying a predetermined weight metric that is based on the performance of the asset pool, and perform value distribution to the asset pool based on the weight of the asset pool, value distributed to the asset pool being available to the one or more asset providers with staked pool tokens; and transmitting a message that is indicative of the value distribution to the asset pool.

In Example 2, the subject matter of Example 1 includes, wherein the operations further comprise: deploying the one or more self-executing contracts to the blockchain network.

In Example 3, the subject matter of any of Examples 1-2 includes, wherein a decentralized finance protocol is implemented on the blockchain network, and the pool tokens represent respective shares of the plurality of asset providers in the asset pool.

In Example 4, the subject matter of any of Examples 1-3 includes, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to: register the asset pool with a yield farming system on the blockchain network.

In Example 5, the subject matter of any of Examples 1-4 includes, wherein the sliding time window has a predetermined duration.

In Example 6, the subject matter of any of Examples 1-5 includes, wherein the sliding time window is a second period in which a state of the asset pool was updated, and the predetermined performance metric tracks the performance of the asset pool by comparing the performance of the asset pool in the second period to the performance of the asset pool in a first period in which the state of the asset pool was updated, the first period being prior to the second period.

In Example 7, the subject matter of Example 6 includes, wherein the predetermined performance metric comprises an Average Price Change (APC) metric, and the performance of the asset pool is tracked by determining an APC associated with the asset pool from the first period to the second period.

In Example 8, the subject matter of Example 7 includes, wherein the performance of the asset pool comprises performance of the asset pool relative to performance of one or more other asset pools, and the predetermined weight metric determines the weight of the asset pool based on the APC associated with the asset pool relative to an APC associated with a group of asset pools, the group of asset pools including the asset pool and the one or more other asset pools.

In Example 9, the subject matter of any of Examples 1-8 includes, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to: detect that the asset pool meets one or more value distribution criteria; and responsive to detecting that the asset pool meets the one or more value distribution criteria, designate the asset pool as value distribution-eligible on the blockchain network.

In Example 10, the subject matter of Example 9 includes, wherein the one or more value distribution criteria comprise at least one of: a minimum duration of pool existence; a minimum number of asset providers; or a minimum pool value.

In Example 11, the subject matter of any of Examples 9-10 includes, wherein the performing of the value distribution to the asset pool comprises: detecting updating of a state of the asset pool; detecting that the asset pool is value distribution-eligible; and responsive to detecting the updating of the state of the asset pool and that the asset pool is value distribution-eligible, performing the value distribution to the asset pool based on the weight of the asset pool.

In Example 12, the subject matter of Example 11 includes, wherein the weight of the asset pool is updated responsive to detecting the updating of the state of the asset pool, and the updating of the state of the asset pool comprises execution, on the blockchain network, of a predetermined transaction against the asset pool.

In Example 13, the subject matter of any of Examples 1-12 includes, wherein the value distribution comprises issuing reward tokens, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to: release reward tokens from a reward token escrow based on a decreasing release schedule; withdraw the released reward tokens from the reward token escrow; and allocate at least some of the released reward tokens to the asset pool.

In Example 14, the subject matter of Example 13 includes, wherein the decreasing release schedule is a halving schedule.

In Example 15, the subject matter of any of Examples 13-14 includes, wherein the pool tokens and the reward tokens are fungible tokens.

In Example 16, the subject matter of any of Examples 13-15 includes, wherein the asset pool is associated with a decentralized finance protocol, and the reward tokens comprise governance tokens of the decentralized finance protocol.

In Example 17, the subject matter of any of Examples 1-16 includes, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to: detect a claim originating from one of the plurality of asset providers; and responsive to detecting the claim, distribute, via the blockchain network, value associated with the asset pool to the asset provider based on staked pool tokens associated with the asset provider.

In Example 18, the subject matter of any of Examples 1-17 includes, wherein the one or more self-executing contracts comprise: a pool manager contract that generates the asset pool on the blockchain network; a value distribution contract associated with the asset pool, the value distribution contract receiving value distributed to the asset pool responsive to updating of a state of the asset pool, and the asset providers being enabled to stake their respective pool tokens in the value distribution contract; and a factory contract that deploys the value distribution contract to the blockchain network responsive to generation of the asset pool.

Example 19 is a method comprising: causing one or more self-executing contracts deployed on a blockchain network to: associate an asset pool with a plurality of asset providers, one or more of the plurality of asset providers staking pool tokens against the asset pool, track performance of the asset pool in a sliding time window by applying a predetermined performance metric, update a weight of the asset pool by applying a predetermined weight metric that is based on the performance of the asset pool, and perform value distribution to the asset pool based on the weight of the asset pool, value distributed to the asset pool being available to the one or more asset providers with staked pool tokens; and transmitting a message that is indicative of the value distribution to the asset pool.

Example 20 is a non-transitory computer-readable medium that stores instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: causing one or more self-executing contracts deployed on a blockchain network to: associate an asset pool with a plurality of asset providers, one or more of the plurality of asset providers staking pool tokens against the asset pool, track performance of the asset pool in a sliding time window by applying a predetermined performance metric, update a weight of the asset pool by applying a predetermined weight metric that is based on the performance of the asset pool, and perform value distribution to the asset pool based on the weight of the asset pool, value distributed to the asset pool being available to the one or more asset providers with staked pool tokens; and transmitting a message that is indicative of the value distribution to the asset pool.

Example 21 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-20.

Example 22 is an apparatus comprising means to implement any of Examples 1-20. Example 23 is a system to implement any of Examples 1-20.

Example 24 is a method to implement any of Examples 1-20.

Although specific examples are described herein, it will be evident that various modifications and changes may be made to these examples without departing from the broader spirit and scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific examples in which the subject matter may be practiced. The examples illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other examples may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This detailed description, therefore, is not to be taken in a limiting sense, and the scope of various examples is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Such examples of the inventive subject matter may be referred to herein, individually or collectively, by the “example” merely for convenience and without intending to voluntarily limit the scope of this application to any single example or concept if more than one is in fact disclosed. Thus, although specific examples have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific examples shown. This disclosure is intended to cover any and all adaptations or variations of various examples. Combinations of the above examples, and other examples not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

For example, while the overall design of the yield farming system may be largely or completely protocol-agnostic, specific metrics used can be adjusted to better suit certain protocols. For instance, the formulas used herein to illustrate performance tracking and weight determination may be suited to asset management protocols, but these formulas or metrics could be adjusted to cater, for example, more specifically for an automated market maker (AMM) protocol. In an AMM protocol, a farming system could assess average liquidity when determining pool weight (e.g., as opposed to the combination of unrealized profits and APC).

The various features, steps, operations, and processes described herein may be used independently of one another, or may be combined in various ways. All possible combinations and subcombinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks or operations may be omitted in some implementations.

Some portions of the subject matter discussed herein may be presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). Such algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.

Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or any suitable combination thereof), registers, or other machine components that receive, store, transmit, or display information. Furthermore, unless specifically stated otherwise, the terms “a” and “an” are herein used, as is common in patent documents, to include one or more than one instance. Finally, as used herein, the conjunction “or” refers to a non-exclusive “or,” unless specifically stated otherwise.

Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense, e.g., in the sense of “including, but not limited to.” As used herein, the terms “connected,” “coupled,” or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof

Additionally, the words “herein,” “above,” “below,” and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words using the singular or plural number may also include the plural or singular number, respectively. The word “or” in reference to a list of two or more items, covers all of the following interpretations of the word: any one of the items in the list, all of the items in the list, and any combination of the items in the list.

As used in this disclosure, phrases of the form “at least one of an A, a B, or a C,” “at least one of A, B, or C,” “at least one of A, B, and C,” and the like, should be interpreted to select at least one from the group that comprises “A, B, and C.” Unless explicitly stated otherwise in connection with a particular instance in this disclosure, this manner of phrasing does not mean “at least one of A, at least one of B, and at least one of C.” As used in this disclosure, the example “at least one of an A, a B, or a C,” would cover any of the following selections: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, and {A, B, C}.

Although some examples, e.g., those depicted in the drawings, include a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example, some of the operations depicted may be performed in parallel or in a different sequence that does not materially affect the functions as described in the examples. In other examples, different components of an example device or system that implements an example method may perform functions at substantially the same time or in a specific sequence.

Claims

1. A system comprising:

at least one memory component that stores instructions; and

one or more processors configured by the instructions to perform operations comprising: causing one or more self-executing contracts deployed on a blockchain network to: associate an asset pool with a plurality of asset providers, one or more of the plurality of asset providers staking pool tokens against the asset pool, track performance of the asset pool in a sliding time window by applying a predetermined performance metric, update a weight of the asset pool by applying a predetermined weight metric that is based on the performance of the asset pool, and perform value distribution to the asset pool based on the weight of the asset pool, value distributed to the asset pool being available to the one or more asset providers with staked pool tokens; and transmitting a message that is indicative of the value distribution to the asset pool.

2. The system of claim 1, wherein the operations further comprise:

deploying the one or more self-executing contracts to the blockchain network.

3. The system of claim 1, wherein a decentralized finance protocol is implemented on the blockchain network, and the pool tokens represent respective shares of the plurality of asset providers in the asset pool.

4. The system of claim 1, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to:

register the asset pool with a yield farming system on the blockchain network.

5. The system of claim 1, wherein the sliding time window has a predetermined duration.

6. The system of claim 1, wherein the sliding time window is a second period in which a state of the asset pool was updated, and the predetermined performance metric tracks the performance of the asset pool by comparing the performance of the asset pool in the second period to the performance of the asset pool in a first period in which the state of the asset pool was updated, the first period being prior to the second period.

7. The system of claim 6, wherein the predetermined performance metric comprises an Average Price Change (APC) metric, and the performance of the asset pool is tracked by determining an APC associated with the asset pool from the first period to the second period.

8. The system of claim 7, wherein the performance of the asset pool comprises performance of the asset pool relative to performance of one or more other asset pools, and the predetermined weight metric determines the weight of the asset pool based on the APC associated with the asset pool relative to an APC associated with a group of asset pools, the group of asset pools including the asset pool and the one or more other asset pools.

9. The system of claim 1, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to:

detect that the asset pool meets one or more value distribution criteria; and

responsive to detecting that the asset pool meets the one or more value distribution criteria, designate the asset pool as value distribution-eligible on the blockchain network.

10. The system of claim 9, wherein the one or more value distribution criteria comprise at least one of: a minimum duration of pool existence; a minimum number of asset providers; or a minimum pool value.

11. The system of claim 9, wherein the performing of the value distribution to the asset pool comprises:

detecting updating of a state of the asset pool;

detecting that the asset pool is value distribution-eligible; and

responsive to detecting the updating of the state of the asset pool and that the asset pool is value distribution-eligible, performing the value distribution to the asset pool based on the weight of the asset pool.

12. The system of claim 11, wherein the weight of the asset pool is updated responsive to detecting the updating of the state of the asset pool, and the updating of the state of the asset pool comprises execution, on the blockchain network, of a predetermined transaction against the asset pool.

13. The system of claim 1, wherein the value distribution comprises issuing reward tokens, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to:

release reward tokens from a reward token escrow based on a decreasing release schedule;

withdraw the released reward tokens from the reward token escrow; and

allocate at least some of the released reward tokens to the asset pool.

14. The system of claim 13, wherein the decreasing release schedule is a halving schedule.

15. The system of claim 13, wherein the pool tokens and the reward tokens are fungible tokens.

16. The system of claim 13, wherein the asset pool is associated with a decentralized finance protocol, and the reward tokens comprise governance tokens of the decentralized finance protocol.

17. The system of claim 1, the operations further comprising causing the one or more self-executing contracts deployed on the blockchain network to:

detect a claim originating from one of the plurality of asset providers; and

responsive to detecting the claim, distribute, via the blockchain network, value associated with the asset pool to the asset provider based on staked pool tokens associated with the asset provider.

18. The system of claim 1, wherein the one or more self-executing contracts comprise:

a pool manager contract that generates the asset pool on the blockchain network;

a value distribution contract associated with the asset pool, the value distribution contract receiving value distributed to the asset pool responsive to updating of a state of the asset pool, and the asset providers being enabled to stake their respective pool tokens in the value distribution contract; and

a factory contract that deploys the value distribution contract to the blockchain network responsive to generation of the asset pool.

19. A method comprising:

causing one or more self-executing contracts deployed on a blockchain network to: associate an asset pool with a plurality of asset providers, one or more of the plurality of asset providers staking pool tokens against the asset pool, track performance of the asset pool in a sliding time window by applying a predetermined performance metric, update a weight of the asset pool by applying a predetermined weight metric that is based on the performance of the asset pool, and perform value distribution to the asset pool based on the weight of the asset pool, value distributed to the asset pool being available to the one or more asset providers with staked pool tokens; and

transmitting a message that is indicative of the value distribution to the asset pool.

20. A non-transitory computer-readable medium that stores instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:

causing one or more self-executing contracts deployed on a blockchain network to: associate an asset pool with a plurality of asset providers, one or more of the plurality of asset providers staking pool tokens against the asset pool, track performance of the asset pool in a sliding time window by applying a predetermined performance metric, update a weight of the asset pool by applying a predetermined weight metric that is based on the performance of the asset pool, and perform value distribution to the asset pool based on the weight of the asset pool, value distributed to the asset pool being available to the one or more asset providers with staked pool tokens; and

transmitting a message that is indicative of the value distribution to the asset pool.