METHOD OF SECURING STABILITY IN VALUE OF A DIGITAL ASSET

Abstract

A Facilitator provides funding to a Payments Source, and props up or otherwise stabilizes the market value of a Digital Asset using a Payments Stream from the Payments Source to purchase and burn or otherwise dispose of purchased units of the Digital Asset.

Claims

1. A method of using a computing system for handling financial transactions that support stability in value of units of a Digital Asset, in which transactions of ownership of rights to the units are stored on a blockchain of a distributed ledger, the method comprising: a Facilitator engaging in a revenue sharing agreement in which the Facilitator provides a Funding Amount to a Payments Source in exchange for the Payments Source sharing portions of the Payments Source's revenue from time to time; making available new units of the Digital Asset as a function of a miner expending computational resources; using at least some of the shared revenue to purchase units of the Digital Asset from an exchange; and deleting the purchased units from the blockchain.

2. (canceled)

3. The method of claim 1, further comprising restricting a publicly available amount of the Digital Asset by limiting a total number of units of the Digital Asset that can be mined.

4. The method of claim 1, wherein individual units of the Digital Asset are non-fungible.

5. The method of claim 1, wherein the revenue sharing agreement provides that the Payments Source pay at least some of the Funding Amount by a repayment date.

6. The method of claim 1, wherein the revenue sharing agreement provides that the Payments Source pay at least some of the Funding Amount on behalf of the Facilitator rather than to the Facilitator.

7. The method of claim 1, wherein the revenue sharing agreement provides that the Funding Amount is paid to or on behalf of the Payments Source over time.

8. The method of claim 1, wherein the revenue sharing agreement provides that the sharing portions are calculated as a percentage of the Payments Source's revenue, and the percentage is a decreasing function of the Payments Source's revenue.

9. The method of claim 1, wherein the revenue sharing agreement provides for a cap on a total amount of the Payments Source's revenue that is paid to the Facilitator.

10. The method of claim 9, wherein an amount of the cap is a function of a total amount of the Payments Source sharing portions paid to the Facilitator over a period of time.

11. The method of claim 1, wherein the Facilitator obtains at least some of the Funding Amount from a Third Party at least in part in exchange for multiple units of the Digital Asset.

12. The method of claim 1, wherein the Facilitator obtains at least some of the Funding Amount from a Third Party at least in part in exchange for the Facilitator sharing portions of the Payments Stream.

13. The method of claim 1, wherein the Facilitator provides at least some of the Funding Amount to the Payments Source as multiple units of the Digital Asset.

14. A system for supporting stability in value of units of a Digital Asset, in which transactions of ownership of rights to the units are stored on a blockchain of a distributed ledger, the system comprising a computer system that execute code to record transactions in which (a) a Facilitator engages in a revenue sharing agreement in which the Facilitator provides a Funding Amount to a Payments Source in exchange for the Payments Source sharing portions of the Payments Source's revenue from time to time; (b) make available new units of the Digital Asset as a function of a miner expending computational resources (c) at least some of the shared revenue to purchase units of the Digital Asset from an exchange; and (d) at least some of the purchased units deleted from the blockchain.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] FIG. 1 is a schematic illustrating in general, aspects of an ecosystem of the inventive subject matter.

[0018] FIG. 2 is a flowchart of steps according to the inventive subject matter.

DETAILED DESCRIPTION

[0019] In FIG. 1, an ecosystem 100 generally includes a Facilitator 110, a Payments Source 120, a Digital Asset 130 and an optional Third Party 140. The Facilitator 110 provides a Funding Amount 150 to the Payments Source 120 in exchange for a Payments Stream 162 and a Repayment Of Principle 164.

[0020] The Facilitator 110 uses monies or other value from one or both of the Payments Stream 162 and a Repayment Of Principle 164 to purchase units of the Digital Asset 130 from the market 132 or private pool. Transactions in the Digital Asset 130 are preferably stored on a Blockchain 134, and Facilitator 110 preferably burns the purchased units of the Digital Asset by having them deleted from blockchain.

[0021] Operations of the Facilitator 110 are handled by Computer System 112.

[0022] In FIG. 2 a method of using a computing system for handling financial transactions 200 generally comprises: [0023] Step 210—A Facilitator providing a Funding Amount to a Payments Source in exchange for the Payments Source sharing portions of the Payments Source's revenue from time to time; [0024] Step 220—Using at least some of the shared revenue to purchase units of the Digital Asset from an exchange; and [0025] Step 230—Burning or otherwise disposing of the purchased units

[0026] As used in the description herein, and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.

[0027] Unless the context dictates the contrary, all ranges set forth herein should be interpreted as being inclusive of their endpoints, and open-ended ranges should be interpreted to include only commercially practical values. Similarly, all lists of values should be considered as inclusive of intermediate values unless the context indicates the contrary.

[0028] All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. “such as”) provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.

[0029] Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.

[0030] It should be appreciated that all calculations contemplated herein, including calculations of index and weighted average values, can be performed by generic or special purpose servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.

[0031] It should be apparent to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims. Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms “comprises” and “comprising” should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refers to at least one of something selected from the group consisting of A, B, C . . . and N, the text should be interpreted as requiring only one element from the group, not A plus N, or B plus N, etc.