U.S. patent application number 17/729860 was filed with the patent office on 2022-08-11 for system, method and program product for modifying a supply of stable value digital asset tokens.
The applicant listed for this patent is Gemini IP, LLC. Invention is credited to Brandon Arvanaghi, Daniel William Halley James, Stephen Judkins, Alex Parkinson, Eric Neiman Winer, Cameron Howard Winklevoss, Tyler Howard Winklevoss.
Application Number | 20220253842 17/729860 |
Document ID | / |
Family ID | 1000006290886 |
Filed Date | 2022-08-11 |
United States Patent
Application |
20220253842 |
Kind Code |
A1 |
James; Daniel William Halley ;
et al. |
August 11, 2022 |
SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE
VALUE DIGITAL ASSET TOKENS
Abstract
The present invention generally relates to a method, system and
program product for modifying a supply of stable value digital
asset tokens tied to a blockchain.
Inventors: |
James; Daniel William Halley;
(Brooklyn, NY) ; Winklevoss; Tyler Howard; (New
York, NY) ; Winklevoss; Cameron Howard; (New York,
NY) ; Arvanaghi; Brandon; (New York, NY) ;
Judkins; Stephen; (Portland, OR) ; Parkinson;
Alex; (Portland, OR) ; Winer; Eric Neiman;
(New York, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Gemini IP, LLC |
New York |
NY |
US |
|
|
Family ID: |
1000006290886 |
Appl. No.: |
17/729860 |
Filed: |
April 26, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16688465 |
Nov 19, 2019 |
|
|
|
17729860 |
|
|
|
|
16421975 |
May 24, 2019 |
10540653 |
|
|
16688465 |
|
|
|
|
16293531 |
Mar 5, 2019 |
10373158 |
|
|
16421975 |
|
|
|
|
16036469 |
Jul 16, 2018 |
10929842 |
|
|
16293531 |
|
|
|
|
16020534 |
Jun 27, 2018 |
10373129 |
|
|
16036469 |
|
|
|
|
15960040 |
Apr 23, 2018 |
10438290 |
|
|
16020534 |
|
|
|
|
16020534 |
Jun 27, 2018 |
10373129 |
|
|
16293531 |
|
|
|
|
16282955 |
Feb 22, 2019 |
|
|
|
16293531 |
|
|
|
|
16280788 |
Feb 20, 2019 |
11139955 |
|
|
16282955 |
|
|
|
|
15973140 |
May 7, 2018 |
|
|
|
16280788 |
|
|
|
|
15960040 |
Apr 23, 2018 |
10438290 |
|
|
16280788 |
|
|
|
|
15973175 |
May 7, 2018 |
|
|
|
16280788 |
|
|
|
|
15920042 |
Mar 13, 2018 |
11282139 |
|
|
16280788 |
|
|
|
|
62728441 |
Sep 7, 2018 |
|
|
|
62721983 |
Aug 23, 2018 |
|
|
|
62764977 |
Aug 17, 2018 |
|
|
|
62689563 |
Jun 25, 2018 |
|
|
|
62683412 |
Jun 11, 2018 |
|
|
|
62660655 |
Apr 20, 2018 |
|
|
|
62647353 |
Mar 23, 2018 |
|
|
|
62638679 |
Mar 5, 2018 |
|
|
|
62660655 |
Apr 20, 2018 |
|
|
|
62647353 |
Mar 23, 2018 |
|
|
|
62638679 |
Mar 5, 2018 |
|
|
|
62660655 |
Apr 20, 2018 |
|
|
|
62647353 |
Mar 23, 2018 |
|
|
|
62638679 |
Mar 5, 2018 |
|
|
|
62689563 |
Jun 25, 2018 |
|
|
|
62683412 |
Jun 11, 2018 |
|
|
|
62689563 |
Jun 25, 2018 |
|
|
|
62683412 |
Jun 11, 2018 |
|
|
|
62684023 |
Jun 12, 2018 |
|
|
|
62680775 |
Jun 5, 2018 |
|
|
|
62702265 |
Jul 23, 2018 |
|
|
|
62764978 |
Aug 17, 2018 |
|
|
|
62732347 |
Sep 17, 2018 |
|
|
|
62660655 |
Apr 20, 2018 |
|
|
|
62642946 |
Mar 14, 2018 |
|
|
|
62642931 |
Mar 14, 2018 |
|
|
|
62629417 |
Feb 12, 2018 |
|
|
|
62660655 |
Apr 20, 2018 |
|
|
|
62647353 |
Mar 23, 2018 |
|
|
|
62638679 |
Mar 5, 2018 |
|
|
|
62642946 |
Mar 14, 2018 |
|
|
|
62642931 |
Mar 14, 2018 |
|
|
|
62660655 |
Apr 20, 2018 |
|
|
|
62629417 |
Feb 12, 2018 |
|
|
|
62629417 |
Feb 12, 2018 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/3829 20130101;
G06Q 20/389 20130101; H04L 9/3247 20130101; H04L 2209/56
20130101 |
International
Class: |
G06Q 20/38 20060101
G06Q020/38; H04L 9/32 20060101 H04L009/32 |
Claims
1. A method comprising: receiving, from a token issuer system and
utilizing a blockchain, a first transaction request to remove a
first amount of digital asset tokens from a balance account,
wherein the first transaction request is digitally signed by an
authorized private key associated with a first smart contract used
to determine the first transaction request is authorized; causing
execution, via geographically distributed computer systems
associated with the blockchain, of a first call request to obtain a
second amount of digital asset tokens that reflect a current
balance of digital asset tokens in the balance account; determining
that the first amount of digital asset tokens is less than or equal
to the second amount of digital asset tokens; based at least in
part on the first amount of digital asset tokens being less than or
equal to the second amount of digital asset tokens, causing
execution, via the geographically distributed computer systems, of
a second call request to set a new balance for the digital asset
tokens to a third amount that equals the second amount less the
first amount; causing execution, via the geographically distributed
computer systems, of a third call request to obtain a total supply
of digital asset tokens in circulation; and sending instructions to
cause the blockchain to set the total supply of digital asset
tokens in circulation to a fourth amount that is the third amount
less the first amount.
2. The method of claim 1, further comprising: providing a first
designated key pair, including a first designated public key and a
corresponding first designated private key, wherein the first
designated public key also corresponds to a first designated public
address associated with an underlying digital asset, wherein the
underlying digital asset is maintained on a distributed public
transaction ledger maintained by the geographically distributed
computer systems, and wherein the first designated private key is
stored on a first computer system which is connected to the
distributed public transaction ledger; providing a second
designated key pair, including a second designated public key and a
corresponding second designated private key, wherein the second
designated public key also corresponds to a second designated
public address associated with the underlying digital asset, and
wherein the second designated private key is stored on a second
computer system which is physically separated from the first
computer system and is not operatively or physically connected to
the distributed public transaction ledger; and wherein the
authorized private key corresponds to at least one of the first
designated private key or the second designated private key.
3. The method of claim 2, further comprising: providing first smart
contract instructions for the first smart contract, the first smart
contract associated with a first contract address, wherein the
first smart contract instructions are saved as part of the
blockchain for the underlying digital asset and include: first
delegation instructions to delegate one or more first functions
associated with the digital asset tokens to one or more delegated
contract addresses associated with the blockchain, wherein the one
or more delegated contract addresses differ from the first contract
address, and wherein a second contract address is designated as one
of the one or more delegated contract addresses; and first
authorization instructions for the second designated key pair.
4. The method of claim 2, further comprising: providing second
smart contract instructions for a second smart contract, the second
smart contract associated with a second contract address, wherein
the second smart contract instructions are saved as part of the
blockchain for the underlying digital asset and include: print
limiter token creation instructions indicating conditions under
which tokens of the digital asset tokens are created; second
authorization instructions to create tokens of the digital asset
tokens, wherein the first designated key pair is designated to
authorize the second authorization instructions to create tokens of
the digital asset tokens; and third authorization instructions with
respect to token creation of the digital asset tokens, wherein the
third authorization instructions designate a first designated
custodian address with respect to token creation of the digital
asset tokens.
5. The method of claim 4, further comprising: providing third smart
contract instructions for a first designated custodian smart
contract associated with a third contract address, wherein the
third contract address is the first designated custodian address,
and wherein the third smart contract instructions are saved as part
of the blockchain associated with the underlying digital asset and
include fourth authorization instructions to authorize issuance of
instructions to the second smart contract regarding token creation,
wherein the fourth authorization instructions designate the second
designated key pair to authorize the fourth authorization
instructions.
6. The method of claim 2, further comprising: providing fourth
smart contract instructions for a fourth smart contract associated
with a fourth contract address, wherein the fourth smart contract
instructions are saved as part of the blockchain associated with
the underlying digital asset and include: token creation
instructions to create tokens of the digital asset tokens in
accordance with conditions set forth by print limiter token
creation instructions; and second delegation instructions
delegating data storage operations to at least another contract
address.
7. The method of claim 6, further comprising: providing fifth smart
contract instructions for a fifth smart contract associated with a
fifth contract address, wherein the fifth contract instructions are
saved as part of the blockchain for the underlying digital asset
and include: data storage instructions for transaction data related
to the digital asset tokens, wherein the transaction data includes
for issued tokens of the digital asset tokens: respective public
address information associated with the blockchain associated with
the underlying digital asset; and corresponding respective token
balance information associated with the respective public address
information; and fifth authorization instructions to modify the
transaction data in response to requests from the fourth contract
address.
8. A system comprising: one or more processors; and non-transitory
computer-readable media storing instructions that, when executed by
the one or more processors, cause the one or more processors to
perform operations comprising: receiving, from a token issuer
system and utilizing a blockchain, a first transaction request to
remove a first amount of digital asset tokens from a balance
account, wherein the first transaction request is digitally signed
by an authorized private key associated with a first smart contract
used to determine the first transaction request is authorized;
causing execution, via geographically distributed computer systems
associated with the blockchain, of a first call request to obtain a
second amount of digital asset tokens that reflect a current
balance of digital asset tokens in the balance account; determining
that the first amount of digital asset tokens is less than or equal
to the second amount of digital asset tokens; based at least in
part on the first amount of digital asset tokens being less than or
equal to the second amount of digital asset tokens, causing
execution, via the geographically distributed computer systems, of
a second call request to set a new balance for the digital asset
tokens to a third amount that equals the second amount less the
first amount; causing execution, via the geographically distributed
computer systems, of a third call request to obtain a total supply
of digital asset tokens in circulation; and sending instructions to
cause the blockchain to set the total supply of digital asset
tokens in circulation to a fourth amount that is the third amount
less the first amount.
9. The system of claim 8, the operations further comprising causing
the first smart contract to execute, via the geographically
distributed computer systems, based at least in part on receiving
the first transaction request.
10. The system of claim 8, the operations further comprising:
providing a first designated key pair, including a first designated
public key and a corresponding first designated private key,
wherein the first designated public key also corresponds to a first
designated public address associated with an underlying digital
asset, wherein the underlying digital asset is maintained on a
distributed public transaction ledger maintained by the
geographically distributed computer systems, and wherein the first
designated private key is stored on a first computer system which
is connected to the distributed public transaction ledger;
providing a second designated key pair, including a second
designated public key and a corresponding second designated private
key, wherein the second designated public key also corresponds to a
second designated public address associated with the underlying
digital asset, and wherein the second designated private key is
stored on a second computer system which is physically separated
from the first computer system and is not operatively or physically
connected to the distributed public transaction ledger; and wherein
the authorized private key corresponds to at least one of the first
designated private key or the second designated private key.
11. The system of claim 10, the operations further comprising:
providing first smart contract instructions for the first smart
contract, the first smart contract associated with a first contract
address, wherein the first smart contract instructions are saved as
part of the blockchain for the underlying digital asset and
include: first delegation instructions to delegate one or more
first functions associated with the digital asset tokens to one or
more delegated contract addresses associated with the blockchain,
wherein the one or more delegated contract addresses differ from
the first contract address, and wherein a second contract address
is designated as one of the one or more delegated contract
addresses; and first authorization instructions for the second
designated key pair.
12. The system of claim 10, further comprising: providing second
smart contract instructions for a second smart contract, the second
smart contract associated with a second contract address, wherein
the second smart contract instructions are saved as part of the
blockchain for the underlying digital asset and include: print
limiter token creation instructions indicating conditions under
which tokens of the digital asset tokens are created; second
authorization instructions to create tokens of the digital asset
tokens, wherein the first designated key pair is designated to
authorize the second authorization instructions to create tokens of
the digital asset tokens; and third authorization instructions with
respect to token creation of the digital asset tokens, wherein the
third authorization instructions designate a first designated
custodian address with respect to token creation of the digital
asset tokens.
13. The system of claim 12, the operations further comprising:
providing third smart contract instructions for a first designated
custodian smart contract associated with a third contract address,
wherein the third contract address is the first designated
custodian address, and wherein the third smart contract
instructions are saved as part of the blockchain associated with
the underlying digital asset and include fourth authorization
instructions to authorize issuance of instructions to the second
smart contract regarding token creation, wherein the fourth
authorization instructions designate the second designated key pair
to authorize the fourth authorization instructions.
14. The system of claim 10, the operations further comprising:
providing fourth smart contract instructions for a fourth smart
contract associated with a fourth contract address, wherein the
fourth smart contract instructions are saved as part of the
blockchain associated with the underlying digital asset and
include: token creation instructions to create tokens of the
digital asset tokens in accordance with conditions set forth by
print limiter token creation instructions; and second delegation
instructions delegating data storage operations to at least another
contract address.
15. The system of claim 14, the operations further comprising:
providing fifth smart contract instructions for a fifth smart
contract associated with a fifth contract address, wherein the
fifth contract instructions are saved as part of the blockchain for
the underlying digital asset and include: data storage instructions
for transaction data related to the digital asset tokens, wherein
the transaction data includes for issued tokens of the digital
asset tokens: respective public address information associated with
the blockchain associated with the underlying digital asset; and
corresponding respective token balance information associated with
the respective public address information; and fifth authorization
instructions to modify the transaction data in response to requests
from the fourth contract address.
16. A method comprising: providing a first designated key pair,
including a first designated public key and a corresponding first
designated private key, wherein the first designated public key
also corresponds to a first designated public address associated
with an underlying digital asset, wherein the underlying digital
asset is maintained on a distributed public transaction ledger
maintained by geographically distributed computer systems;
receiving, from a token issuer system and utilizing a blockchain, a
first transaction request to remove a first amount of digital asset
tokens from a balance account, wherein the first transaction
request is digitally signed by the first designated private key
associated with a first smart contract used to determine the first
transaction request is authorized; causing execution, via
geographically distributed computer systems associated with the
blockchain, of a first call request to obtain a second amount of
digital asset tokens that reflect a current balance of digital
asset tokens in the balance account; determining that the first
amount of digital asset tokens is less than or equal to the second
amount of digital asset tokens; based at least in part on the first
amount of digital asset tokens being less than or equal to the
second amount of digital asset tokens, causing execution, via the
geographically distributed computer systems, of a second call
request to set a new balance for the digital asset tokens to a
third amount that equals the second amount less the first amount;
causing execution, via the geographically distributed computer
systems, of a third call request to obtain a total supply of
digital asset tokens in circulation; and sending instructions to
cause the blockchain to set the total supply of digital asset
tokens in circulation to a fourth amount that is the third amount
less the first amount.
17. The method of claim 16, further comprising providing smart
contract instructions for a second smart contract, the second smart
contract associated with a second contract address, wherein the
smart contract instructions are saved as part of the blockchain for
the underlying digital asset and include instructions for modifying
the total supply of the digital asset tokens.
18. The method of claim 16, wherein: causing execution of the first
call comprises causing execution of the first call based at least
in part on first smart contract instructions; causing execution of
the second call comprises causing execution of the second call
based at least in part on second smart contract instructions that
differ from the first smart contract instructions; and causing
execution of the third call comprises causing execution of the
third call based at least in part on third smart contract
instructions that differ from both the first smart contract
instructions and the second smart contract instructions.
19. The method of claim 16, further comprising authorizing the
first transaction request based at least in part on designated
public addresses associated with public keys for the first
transaction request, designated private addresses associated with
private keys for the first transaction request, and smart contract
instructions indicating authorized designated public addresses and
authorized designated private addresses.
20. The method of claim 16, further comprising sending a response
to the first transaction request, the response indicating that the
first transaction request has been accepted and indicating the
total supply of the digital asset tokens has been set to the fourth
amount.
Description
REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 16/688,465, filed on Nov. 19, 2019 and
entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR MODIFYING A SUPPLY
OF STABLE VALUE DIGITAL ASSET TOKENS, which is a continuation of
and claims priority to U.S. patent application Ser. No. 16/421,975,
filed on May 24, 2019 and entitled SYSTEM, METHOD AND PROGRAM
PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET
TOKENS, which is a continuation of U.S. patent application Ser. No.
16/293,531, filed on Mar. 5, 2019 and entitled SYSTEM, METHOD AND
PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL
ASSET TOKENS which claims the benefit of and priority to each of
U.S. Provisional Application No. 62/638,679, filed on Mar. 5, 2018
and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND
UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application
No. 62/647,353, filed on Mar. 23, 2018 and entitled SYSTEM, METHOD
AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE
DIGITAL ASSETS; U.S. Provisional Application No. 62/660,655, filed
on Apr. 20, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT
FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; U.S.
Provisional Application No. 62/683,412, filed on Jun. 11, 2018 and
entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND
UTILIZING STABLE VALUE DIGITAL ASSETS; U.S. Provisional Application
No. 62/689,563, filed on Jun. 25, 2018 and entitled SYSTEM, METHOD
AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE
DIGITAL ASSETS; U.S. Provisional Application Ser. No. 62/764,977,
filed on Aug. 17, 2018 and entitled SYSTEM, METHOD, AND PROGRAM
PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET
TOKENS; U.S. Provisional Patent Application Ser. No. 62/721,983,
filed on Aug. 23, 2018 and entitled SYSTEM, METHOD, AND PROGRAM
PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET
TOKENS; and U.S. Provisional Patent Application Ser. No.
62/728,441, filed on Sep. 7, 2018 and entitled SYSTEM, METHOD, AND
PROGRAM PRODUCT FOR MODIFYING A SUPPLY OF STABLE VALUE DIGITAL
ASSET TOKENS, the entire content of each of which is hereby
incorporated by reference herein.
[0002] U.S. patent application Ser. No. 16/293,531, filed on Mar.
5, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR
MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS also claims
priority as a continuation-in-part to U.S. patent application Ser.
No. 16/036,469, filed on Jul. 16, 2018 and entitled SYSTEM, METHOD,
AND PROGRAM PRODUCT FOR DEPOSITING AND WITHDRAWING STABLE VALUE
DIGITAL ASSETS IN EXCHANGE FOR FIAT, which in turn is a
continuation-in-part of U.S. patent application Ser. No.
16/020,534, filed on Jun. 27, 2018 and entitled SYSTEM, METHOD, AND
PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL
ASSETS, which in turn is a continuation-in-part of U.S. patent
application Ser. No. 15/960,040, filed on Apr. 23, 2018 and
entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND
UTILIZING STABLE VALUE DIGITAL ASSETS, which claims priority to and
the benefit of each of U.S. Provisional Patent Application No.
62/660,655, filed on Apr. 20, 2018 and entitled SYSTEM, METHOD AND
PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL
ASSETS, U.S. Provisional Patent Application No. 62/647,353, filed
on Mar. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT
FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, and U.S.
Provisional Patent Application No. 62/638,679, filed on Mar. 5,
2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING
AND UTILIZING STABLE VALUE DIGITAL ASSETS, the entire content of
each of which is hereby incorporated by reference herein.
[0003] U.S. patent application Ser. No. 16/293,531, filed on Mar.
5, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR
MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS also claims
priority as a continuation-in-part to U.S. patent application Ser.
No. 15/960,040, filed on Apr. 23, 2018 and entitled SYSTEM, METHOD
AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE
DIGITAL ASSETS, which claims priority to and the benefit of each
of: U.S. Provisional Patent Application No. 62/660,655, filed on
Apr. 20, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR
GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, U.S.
Provisional Patent Application No. 62/647,353, filed on Mar. 23,
2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING
AND UTILIZING STABLE VALUE DIGITAL ASSETS, and U.S. Provisional
Patent Application No. 62/638,679, filed on Mar. 5, 2018 and
entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND
UTILIZING STABLE VALUE DIGITAL ASSETS, the entire content of each
of which is hereby incorporated by reference herein.
[0004] U.S. patent application Ser. No. 16/293,531, filed on Mar.
5, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR
MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS also claims
priority as a continuation-in-part to U.S. patent application Ser.
No. 16/020,534 filed on Jun. 27, 2018 and entitled SYSTEM, METHOD,
AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE
DIGITAL ASSETS, which claims the benefit of and priority to each of
U.S. Provisional Patent Application Ser. No. 62/689,563, filed on
Jun. 25, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR
GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS; and U.S.
Provisional Patent Application No. 62/683,412, filed Jun. 11, 2018
and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND
UTILIZING STABLE VALUE DIGITAL ASSETS, the entire content of each
of which is hereby incorporated by reference herein.
[0005] U.S. patent application Ser. No. 16/036,469 also claims the
benefit of and priority to each of U.S. Provisional Patent
Application Ser. No. 62/689,563, filed on Jun. 25, 2018 and
entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND
UTILIZING STABLE VALUE DIGITAL ASSETS; and U.S. Provisional Patent
Application No. 62/683,412, filed Jun. 11, 2018 and entitled
SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING
STABLE VALUE DIGITAL ASSETS, the entire content of each of which is
hereby incorporated by reference herein.
[0006] U.S. patent application Ser. No. 16/293,531, filed on Mar.
5, 2019 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR
MODIFYING A SUPPLY OF STABLE VALUE DIGITAL ASSET TOKENS also claims
priority as a continuation-in-part to U.S. patent application Ser.
No. 16/282,955, filed on Feb. 22, 2019 and entitled SYSTEMS,
METHODS, AND PROGRAM PRODUCTS FOR DEPOSITING, HOLDING, AND/OR
DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON
AN UNDERLYING BLOCKCHAIN, which in turn is a continuation-in-part
to U.S. Non-Provisional patent application Ser. No. 16/280,788,
filed Feb. 20, 2019 and entitled SYSTEMS, METHODS, AND PROGRAM
PRODUCTS FOR LOANING DIGITAL ASSETS AND FOR DEPOSITING, HOLDING
AND/OR DISTRIBUTING COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL
ASSETS ON AN UNDERLYING BLOCKCHAIN, which in turn claims priority
to U.S. Provisional Application Ser. No. 62/684,023 filed on Jun.
12, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR
LOANING DIGITAL ASSETS; U.S. Provisional Application No.
62/680,775, filed on Jun. 5, 2018 and entitled SYSTEMS, METHODS,
AND PROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS; U.S. Provisional
Application No. 62/702,265, filed on Jul. 23, 2018 and entitled
SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR LOANING DIGITAL ASSETS
AND FOR DEPOSITING, HOLDING, AND/OR DISTRIBUTING COLLATERAL AS A
TOKEN ON AN UNDERLYING BLOCKCHAIN; U.S. Provisional Patent
Application Ser. No. 62/764,978, filed on Aug. 17, 2018 and
entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR GENERATING USER
DEFINED SMART CONTRACTS AND DEPOSITING, HOLDING AND/OR DISTRIBUTING
COLLATERAL AS A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN
UNDERLYING BLOCKCHAIN; and U.S. Provisional Patent Application Ser.
No. 62/732,347, filed on Sep. 17, 2018 and entitled SYSTEMS,
METHODS, AND PROGRAM PRODUCTS FOR GENERATING USER DEFINED SMART
CONTRACTS AND DEPOSITING, HOLDING AND/OR DISTRIBUTING COLLATERAL AS
A TOKEN IN THE FORM OF DIGITAL ASSETS ON AN UNDERLYING BLOCKCHAIN,
the entire content of each of each of which is hereby incorporated
by reference herein. U.S. Non-Provisional patent application Ser.
No. 16/280,788 also claims priority as a continuation-in-part to
U.S. Non-Provisional patent application Ser. No. 15/973,140, filed
on May 7, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS
FOR EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS,
which in turn claims priority to U.S. Provisional Patent
Application Ser. No. 62/660,655, filed on Apr. 20, 2018 and
entitled SYSTEM, METHOD AND PROGRAM PRODUCT FOR GENERATING AND
UTILIZING STABLE VALUE DIGITAL ASSETS, U.S. Provisional Patent
Application Ser. No. 62/642,946, filed on Mar. 14, 2018 and
entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING
DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, U.S.
Provisional Patent Application Ser. No. 62/642,931, filed on Mar.
14, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR
EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, and
U.S. Provisional Patent Application Ser. No. 62/629,417, filed on
Feb. 12, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS
FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET
WALLET, the entire content of each of which is hereby incorporated
by reference herein. U.S. Non-Provisional patent application Ser.
No. 16/280,788 also claims priority as a continuation-in-part to
U.S. Non-Provisional patent application Ser. No. 15/960,040, filed
on Apr. 23, 2018 and entitled SYSTEM, METHOD AND PROGRAM PRODUCT
FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, which in
turn claims priority to U.S. Provisional Patent Application Ser.
No. 62/660,655, filed on Apr. 20, 2018 and entitled SYSTEM, METHOD
AND PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE
DIGITAL ASSETS, and U.S. Provisional Patent Application Ser. No.
62/647,353, filed on Mar. 23, 2018 and entitled SYSTEM, METHOD AND
PROGRAM PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL
ASSETS and U.S. Provisional Patent Application Ser. No. 62/638,679,
filed on Mar. 5, 2018 and entitled SYSTEM, METHOD AND PROGRAM
PRODUCT FOR GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS,
the entire content of each of which is hereby incorporated by
reference herein. U.S. Non-Provisional patent application Ser. No.
16/280,788 also claims priority as a continuation-in-part to U.S.
Non-Provisional patent application Ser. No. 15/973,175, filed on
May 7, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR
EXCHANGING DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS,
which in turn claims priority to U.S. Provisional Patent
Application No. 62/642,946, filed on Mar. 14, 2018 and entitled
SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING DIGITAL
ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, and U.S. Provisional
Patent Application No. 62/642,931 filed on Mar. 14, 2018 and
entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR EXCHANGING
DIGITAL ASSETS FOR FIAT AND/OR OTHER DIGITAL ASSETS, and U.S.
Provisional Patent Application Ser. No. 62/629,417, filed Feb. 12,
2018 entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING
DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET WALLET, and U.S.
Provisional Patent Application Ser. No. 62/660,655 filed on Apr.
20, 2018 and entitled SYSTEMS, METHODS, and PROGRAM PRODUCT FOR
GENERATING AND UTILIZING STABLE VALUE DIGITAL ASSETS, the entire
content of each of which is hereby incorporated by reference
herein. U.S. Non-Provisional patent application Ser. No. 16/280,788
also claims priority as a continuation-in-part to U.S.
Non-Provisional patent application Ser. No. 15/920,042, filed on
Mar. 13, 2018 and entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS
FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL DIGITAL ASSET
WALLET, which in turn claims priority to U.S. Provisional Patent
Application No. 62/629,417 filed Feb. 12, 2018 and entitled
SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS
HELD IN A CUSTODIAL DIGITAL ASSET WALLET, the entire content of
each of which is hereby incorporated by reference herein.
FIELD
[0007] The present invention relates to a method, system, and
program product relating to modifying a supply of digital asset
tokens on an underlying blockchain.
BACKGROUND
[0008] In recent times, using blockchain technology and/or tokens
to track inventory, including potentially, equities or shares in a
fund has been a subject of a lot of discussion. Moreover, the use
of smart contracts to generate tokens on a blockchain have also
become the subject of a lot of discussion.
[0009] However, current blockchain technology, as implemented, does
not have adequate technological solutions to provide for modifying
a supply of stable value digital asset tokens.
[0010] Accordingly, it would be beneficial to provide for a method,
system and program product that provide for modifying a supply of
stable value digital asset tokens using current blockchain
technology and thus avoid the problems discussed above.
SUMMARY
[0011] An object of the present invention is to address
technological challenges that currently exist in modifying a supply
of stable value digital asset tokens tied to underlying blockchain
technology associated with another digital asset.
[0012] This and other objects shall be addressed by embodiments of
the present invention as set forth herein.
[0013] The present invention generally relates to a system, method
and program product for modifying a supply stable value digital
asset tokens tied to an underlying blockchain.
[0014] In embodiments, the present invention generally relates to
the use of stable value digital assets as a cryptocurrency that can
be linked to other digital assets using blockchain technology. In
embodiments, the present invention relates to specific applications
of stable value digital asset tokens tied to a blockchain.
[0015] A stable value digital asset token (e.g., SVCoin) is
provided which may be pegged to a fiat currency such as USD, Euro,
Yen, to name a few. For example, 1 SVCoin will have a net asset
value ("NAV") of $1 USD. In embodiments, 100 SVCoins may have a NAV
of $1 USD, so that 1 SVCoin has a NAV of 1 penny. Unlike Bitcoin
and many other crypto protocols, the SVCoin will not have a natural
cap (e.g., 22 million bitcoins) and, because it is pegged to a fiat
currency, it will not fluctuate in value against such fiat currency
as is typical of many crypto currencies.
[0016] In embodiments, the SVCoin can be issued by a trusted
entity, like a digital asset exchange, bank, or other trusted
entity using a token on an established blockchain, like ether or
bitcoin, and smart contract technology. Thus, for example, a buyer
can provide the trusted entity (e.g., digital asset exchange, bank,
etc.) with a fixed sum of fiat (e.g., 50 USD) and in return be
issued a corresponding fixed sum of SVCoin (e.g., 50 SVCoin). In
embodiments, the digital asset exchange can be a regulated trust,
such as Gemini Trust Company LLC ("Gemini"). In embodiments, other
types of trusted entities (e.g., banks, trusts, etc.) may also be
used to issue, administer, redeem, and/or otherwise manage the
SVCoin. In embodiments, the trusted entity (digital asset exchange,
bank, etc.) can charge a processing fee for issuing the SVCoin
either in fiat or in a digital asset, such as the SVCoin. In
embodiments, fiat deposited to the trusted entity (e.g., digital
asset exchange) is maintained by the trusted entity on par with the
amounts deposited. Thus, in embodiments, SVCoin is collateralized
by fiat. SVCoin holders can also exchange SVCoin for fiat on the
same notional basis with the trusted entity.
[0017] In embodiments, a method of increasing a total supply of
digital asset tokens including the steps of: (a) providing a first
designated key pair, including a first designated public key and a
corresponding first designated private key, wherein the first
designated public key also corresponds to a first designated public
address associated with an underlying digital asset; wherein the
underlying digital asset is maintained on a distributed public
transaction ledger maintained in the form of a blockchain by a
plurality of geographically distributed computer systems in a
peer-to-peer network in the form of a blockchain network, and
wherein the first designated private key is stored on a first
computer system which is connected to the distributed public
transaction ledger through the Internet; (b) providing a second
designated key pair, including a second designated public key and a
corresponding second designated private key, wherein the second
designated public key also corresponds to a first designated public
address associated with the underlying digital asset; wherein the
second designated private key is stored on a second computer system
which is physically separated from the first computer system and is
not operatively or physically connected to the distributed public
transaction ledger or the Internet; (c) providing first smart
contract instructions associated with a first smart contract
associated with a digital asset token associated with a first
contract address associated with the blockchain associated with the
underlying digital asset, wherein the first smart contract
instructions are saved as part of the blockchain for the underlying
digital asset and include: (1) first delegation instructions to
delegate one or more first functions associated with the digital
asset token to one or more delegated contract addresses associated
with the blockchain associated with the underlying digital asset,
wherein the one or more delegated contract addresses are different
from the first contract address, and wherein a second contract
address is designated as one of the one or more delegated contract
addresses; (2) first authorization instructions associated with the
second designated key pair; (d) providing second smart contract
instructions associated with a second smart contract associated
with the digital asset token associated with the second contract
address associated with the blockchain associated with the
underlying digital asset, wherein the second smart contract
instructions are saved as part of the blockchain for the underlying
digital assets and include: (1) print limiter token creation
instructions indicating conditions under which tokens of the
digital asset token are created; (2) second authorization
instructions to create tokens of the digital asset token, wherein
the first designated key pair is designated to authorize said
second authorization instructions to create tokens of the digital
asset token; (3) third authorization instructions with respect to
token creation of the digital asset token; wherein the third
authorization instructions designate a first designated custodian
address with respect to token creation of the digital asset token;
(e) providing third smart contract instructions associated with a
first designated custodian contract associated with the digital
asset token associated with a third contract address associated
with the blockchain associated with the underlying digital asset,
wherein the third contract address is the first designated
custodian contract address, and wherein the third smart contract
instructions are saved as part of the blockchain for the underlying
digital assets and include: (1) fourth authorization instructions
to authorize issuance of instructions to the second smart contract
regarding token creation; wherein the fourth authorization
instructions designate the second designated key pair to authorize
the fourth authorization instructions; (f) providing fourth smart
contract instructions associated with a fourth smart contract
associated with the digital asset token associated with a fourth
contract address associated with the blockchain associated with the
underlying digital asset, wherein the fourth contract address is
one of the one or more delegated contract addresses and not: (i)
the first contract address, (ii) the second contract address, or
(iii) the third contract address, wherein the fourth smart contract
instructions are saved as part of the blockchain associated with
the underlying digital assets and include: (1) token creation
instructions to create tokens of the digital asset tokens in
accordance with conditions set forth by the print limiter token
creation instructions; (2) second delegation instructions
delegating data storage operations to at least a fifth contract
address; (g) providing fifth smart contract instructions associated
with a fifth smart contract associated with the digital asset token
associated with the fifth contract address associated with the
blockchain associated with the underlying digital asset, wherein
the fifth contract address is one of one or more designated store
contract addresses, and wherein the fifth smart contract
instructions are saved as part of the blockchain for the underlying
digital assets and include: (1) data storage instructions for
transaction data related to the digital asset token, wherein the
transaction data includes for all issued tokens of the digital
asset token: (A) respective public address information associated
with the blockchain associated with the underlying digital asset;
and (B) corresponding respective token balance information
associated with said respective public address information; (2)
fifth authorization instructions to modify the transaction data in
response to a request from the fourth contract address; (h)
increasing the total supply of the digital asset tokens, by a
digital asset token issuer system, from a first amount of the
digital asset tokens to a second amount of the digital asset
tokens, including the steps of: (1) generating, by the digital
asset token issuer system, a first transaction request including a
first message including a first request to increase the total
supply of the digital asset tokens to the second amount of digital
asset tokens, to the fourth contract address, wherein the first
transaction request is digitally signed by the first designated
private key; (2) sending, by the digital asset token issuer system
via the blockchain network, the first transaction request from the
first designated public address to the fourth contract address; (3)
sending, by the digital asset token issuer system via the
blockchain network, the first transaction request from the fourth
contract address to the second contract address; wherein the second
smart contract executes, via the plurality of geographically
distributed computer systems in the peer-to-peer network with
reference to the blockchain, the first transaction request to
return a first unique lock identifier associated with the first
transaction request; (4) obtaining, by the digital asset token
issuer system, the first unique lock identifier, based on reference
to the blockchain; (5) generating, by the digital asset token
issuer system, a second transaction request including a second
message including a second request to unlock the total supply of
the digital asset tokens in accordance with the first request and
including the first unique lock identifier, wherein the second
transaction request being to the third contract address, and
digitally signed by the first designated private key; (6) sending,
by the digital asset token issuer system via the blockchain
network, the second transaction request from the first designated
public address to the third contract address, wherein the third
smart contract executes, via the plurality of geographically
distributed computer systems in the peer-to-peer network with
reference to the blockchain, the second transaction request to
return a first unique request hash associated with the second
transaction request; (7) obtaining, by the digital asset token
issuer system, the first unique request hash, based on reference to
the blockchain; (8) generating, by the digital asset token issuer
system, a third transaction request to be digitally signed by at
least the second designated private key including the first unique
request hash; (9) transferring, from the digital asset token issuer
system to a first portable memory device, the third transaction
request; (10) transferring, from the first portable memory device
to the second computer system, the third transaction request; (11)
digitally signing, by the second computer system, the third
transaction request using the second designated private key to
generate a third digitally signed transaction request; (12)
sending, from the second portable memory device using the digital
asset token issuer system, via the blockchain network, the third
digitally signed transaction request to the third contract address;
wherein the third smart contract, executes, via the plurality of
geographically distributed computer systems in the peer-to-peer
network with reference to the blockchain, the third digitally
signed transaction request to validate the second request to unlock
based on the third digitally signed transaction request and the
first unique request hash and executes a first call to the second
contract address, to increase the total supply of the digital asset
tokens to the second amount of digital asset tokens, wherein the
second contract address returns the first call to the fourth
contract address and the fourth smart contract executes, via the
plurality of geographically distributed computer systems in the
peer-to-peer network with reference to the blockchain, a second
call to the fifth contract address to set the total supply of the
digital asset tokens to the second amount of digital asset tokens,
wherein the fifth smart contract executes, via the plurality of
geographically distributed computer systems in the peer-to-peer
network with reference to the blockchain, the second call to set
the total supply of the digital asset tokens to the second amount
of digital asset tokens; and (i) confirming, by the digital asset
token issuer system, the total supply of digital asset tokens is
set to the second amount of digital asset tokens based on reference
to the blockchain.
[0018] In embodiments, the first designated key pair includes an
additional designated key pair including a first additional
designated public key and a corresponding first additional
designated private key, wherein the first additional designated
public key also corresponds to a first additional designated public
address associated with the underlying digital asset.
[0019] In embodiments, the second computer system is a hardware
storage module. In embodiments, the second designated key set
includes an additional designated key set including a second
additional designated public address and a second additional
designated private key.
[0020] In embodiments, the second authorization instructions for
the first designated key set with respect to token creation of the
digital asset token includes instructions limiting creation of
digital asset tokens above a first threshold amount over a first
period of time.
[0021] In embodiments, the fourth authorization instructions
include instructions to permit creation of digital asset tokens
above the first threshold during the first period of time, wherein
the fourth authorization instructions designate the second
designated key pair to authorize the instructions to permit
creation of digital asset tokens above the first threshold.
[0022] In embodiments, the third smart contract instructions
further include: (2) sixth authorization instructions to designate
a seventh contract address as one of the one or more delegated
contract addresses, wherein the seventh contract address is not the
second contract address, and wherein the second designated key pair
is designated to authorize the sixth authorization
instructions.
[0023] In embodiments, the fourth smart contract instructions
further include: (3) token transfer instructions related to
transferring issued tokens of the digital asset token from a first
designated contract address to a second designated contract
address. In embodiments, the fourth smart contract instructions
further include: (3) token destruction instructions related to
destroying one or more issued token of the digital asset token. In
embodiments, the fourth smart contract instructions further
include: (3) token transfer instructions related to transferring
issued tokens of the digital asset token from a first designated
contract address to a second designated contract address; and (4)
token destruction instructions related to destroying one or more
issued tokens of the digital asset token.
[0024] In embodiments, the second smart contract instructions
further include: (4) token balance modification instructions
related to modifying the total balance of tokens of the digital
asset token assigned to a third designated address.
[0025] In embodiments, the first transaction request includes first
transaction fee information for miners associated with the
plurality of geographically distributed computer systems in the
peer-to-peer network to process the first transaction request. In
embodiments, the second transaction request includes second
transaction fee information for miners associated with the
plurality of geographically distributed computer systems in the
peer-to-peer network to process the second transaction request.
[0026] In embodiments, the first portable memory device includes
the second portable memory device.
[0027] In embodiments, the second smart contract instructions
include sixth authorization instructions to modify the total token
supply amount of the digital asset tokens.
[0028] In embodiments, the underlying digital asset is a stable
value token. In embodiments, the underlying digital asset is Neo.
In embodiments, the underlying digital asset is Ether. In
embodiments, the underlying digital asset is Bitcoin.
[0029] In embodiments, the first designated private key is
mathematically related to a first designated public key.
[0030] In embodiments, the first designated public address includes
the first designated public key.
[0031] In embodiments, the first designated public address includes
a hash of the first designated public key.
[0032] In embodiments, the first designated public address includes
a partial hash of the first designated public key.
[0033] In embodiments, the second designated private key is
mathematically related to a second designated public key.
[0034] In embodiments, the second designated public address
includes the second designated public key.
[0035] In embodiments, the second designated public address
includes a hash of the second designated public key.
[0036] In embodiments, the second designated public address
includes a partial hash of the second designated public key.
[0037] In embodiments, a method of increasing a total supply of
digital asset tokens including the steps of: (a) providing a first
designated key pair, including a first designated public key and a
corresponding first designated private key, wherein the first
designated public key also corresponds to a first designated public
address associated with an underlying digital asset; wherein the
underlying digital asset is maintained on a distributed public
transaction ledger maintained in the form of a blockchain by a
plurality of geographically distributed computer systems in a
peer-to-peer network in the form of a blockchain network, and
wherein the first designated private key is stored on a first
computer system which is connected to the distributed public
transaction ledger through the Internet; (b) providing a second
designated key pair, including a second designated public key and a
corresponding second designated private key wherein the second
designated public key also corresponds to a second designated
public address associated with the underlying digital asset,
wherein the second designated private key is stored on a second
computer system which is physically separated from the first
computer system and is not operatively or physically connected to
the distributed public transaction ledger or the Internet; (c)
providing first smart contract instructions associated with a first
smart contract associated with a digital asset token associated
with a first contract address associated with the blockchain
associated with the underlying digital asset, wherein the first
smart contract instructions are saved as part of the blockchain for
the underlying digital assets and include: first delegation
instructions to delegate one or more first functions associated
with the digital asset token to one or more delegated contract
addresses associated with the blockchain associated with the
underlying digital asset, wherein the one or more delegated
contract addresses is different from the first contract address,
and wherein a second contract address is designated as one of the
one or more delegated contract addresses; (1) first authorization
instructions for the second designated key pair; (d) providing
second smart contract instructions associated with a second smart
contract associated with the digital asset token associated with
the second smart contract address associated with the blockchain
associated with the underlying digital asset, wherein the second
smart contract instructions are saved as part of the blockchain for
the underlying digital asset and include: (1) print limiter token
creation instructions indicating conditions under which tokens of
the digital asset token are created; (2) second authorization
instructions to create tokens of the digital asset token, wherein
the first designated key pair is designated to authorize said
second authorization instructions to create tokens of the digital
asset token; and (3) third authorization instructions with respect
to token creation of the digital asset token; wherein the third
authorization instructions designate a first designated custodian
address with respect to token creation of the digital asset token;
(e) providing third smart contract instructions associated with a
first designated custodian smart contract associated with the
digital asset token associated with a third contract address
associated with the blockchain associated with the underlying
digital asset, wherein the third contract address is the first
designated custodian contract address, and wherein the third smart
contract instructions are saved as part of the blockchain
associated with the underlying digital asset and include: fourth
authorization instructions to authorize issuance of instructions to
the second smart contract regarding token creation; wherein the
fourth authorization instructions designate the second designated
key pair to authorize the fourth authorization instructions;
providing fourth smart contract instructions associated with a
fourth smart contract associated with the digital asset token
associated with a fourth contract address associated with the
blockchain associated with the underlying digital asset, wherein
the fourth contract address is one of the one or more delegated
contract addresses and not: (i) the first contract address, (ii)
the second contract address, or (iii) the third contract address,
wherein the fourth smart contract instructions are saved as part of
the blockchain associated with the underlying digital assets and
include: (1) token creation instructions to create tokens of the
digital asset token in accordance with conditions set forth by the
print limiter token creation instructions; and (2) second
delegation instructions delegating data storage operations to at
least a fifth contract address; (f) providing fifth smart contract
instructions associated with a fifth smart contract associated with
the digital asset token associated with the fifth contract address
associated with the blockchain associated with the underlying
digital asset, wherein the fifth smart contract address is one of
the one or more designated store contract addresses, and wherein
the fifth smart contract instructions are saved as part of the
blockchain for the underlying digital assets and include: (1) data
storage instructions for transaction data related to the digital
asset token, wherein said transaction data includes for all issued
tokens of the digital asset token: (A) respective public address
information associated with the blockchain associated with the
underlying digital asset; and (B) corresponding respective token
balance information associated with said respective public address
information; (1) fifth authorization instructions to modify the
transaction data in response to requests from the fourth contract
address; (g) receiving, by a digital asset token issuer system, a
request to generate and assign to the first designated public
address a first amount of digital asset tokens; (h) generating, by
the digital asset token issuer system, the first amount of digital
asset tokens and assigning said first amount of digital asset
tokens to the first designated public address increasing the total
supply of the digital asset tokens, including the steps of: (1)
generating, by the digital asset token issuer system, and sending,
using the digital asset token issuer system via the blockchain
network, a first transaction request: (A) to the fourth contract
address; and (B) including a first message including a first
request to generate the first amount of digital asset tokens and
assign said first amount of digital asset tokens to the first
designated public address; wherein the first transaction request is
digitally signed by the first designated private key; wherein the
fourth smart contract executes, via the plurality of geographically
distributed computer systems in the peer-to-peer network with
reference to the blockchain, the first transaction request to: (i)
validate the first request and the authority of the first
designated private key to call the second smart contract to execute
the first request; and (ii) send a first call to the fourth
contract address to generate and assign to the first designated
public address the first amount of digital asset tokens; wherein
the fourth smart contract executes, via the plurality of
geographically distributed computer systems in the peer-to-peer
network with reference to the blockchain, the first call to
generate a first unique lock identifier, and return to the second
smart contract address, the first unique lock identifier; wherein,
in response to the return of the first unique lock identifier, the
second smart contract executes, via the plurality of geographically
distributed computer systems in the peer-to-peer network with
reference to the blockchain, a call to the fourth smart contract
address to confirm the first call with the first lock identifier;
wherein, in response, the fourth smart contract executes, via the
plurality of geographically distributed computer systems in the
peer-to-peer network with reference to the blockchain, the first
call to execute a second call to the fifth contract address to
obtain the total supply of digital asset tokens in circulation;
wherein, in response, the fifth smart contract executes, via the
plurality of geographically distributed computer systems in the
peer-to-peer network with reference to the blockchain, the second
call and returns, to the fourth contract address, a second amount
of digital asset tokens corresponding to the total supply of
digital asset tokens in circulation; wherein, in response to the
return of the second amount, the fourth smart contract, executes
via the plurality of geographically distributed computer systems in
the peer-to-peer network with reference to the blockchain, a third
call request to the fifth contract address to set a new total
supply of digital asset tokens in circulation to a third amount,
which is the total of the first amount and the second amount;
wherein, in response to the third call, the fifth smart contract,
executes via the plurality of geographically distributed computer
systems in the peer-to-peer network with reference to the
blockchain, the third call and sets a new total supply of digital
asset tokens in circulation at the third amount; wherein, the
fourth smart contract executes, via the plurality of geographically
distributed computer systems in the peer-to-peer network with
reference to the blockchain, a fourth call to the fifth contract
address to add the first amount of digital asset tokens to a
respective balance associated with the first designated public
address; wherein, in response, the fifth smart contract executes,
via the plurality of geographically distributed computer systems in
the peer-to-peer network with reference to the blockchain, the
fourth call to set the balance of digital asset tokens in the first
designated public address at a fourth amount which includes the
addition of the first amount to the previous balance; and (i)
confirming, by the digital asset token issuer system, that the
balance of digital asset tokens associated with the first
designated public address is set to include the first amount of
digital asset tokens based on reference to the blockchain.
[0038] In embodiments, the second computer system is a hardware
storage module.
[0039] In embodiments, the second designated key set includes an
additional designated key set including an additional designated
public address and an additional designated private key.
[0040] In embodiments, the second authorization instructions for
the first designated key set with respect to token creation of the
digital asset token include instruction limiting token creation
above a first threshold over a first period of time. In
embodiments, the fourth authorization instructions for the second
designated key set to authorize the issuance of instructions to the
second smart contract instructions with respect to token creation
include instructions to allow for creation of digital asset tokens
above the first threshold during the first period of time. In
embodiments, the third smart contract instructions further include:
(2) sixth authorization instructions to designate a seventh
contract address as one of the one or more delegated contract
addresses, wherein the seventh contract address is not the second
contract address, and wherein the second designated key set is
designated to authorize the sixth authorization instructions.
[0041] In embodiments, the fourth smart contract instructions
further include: (3) token transfer instructions related to
transferring tokens of the digital asset token from a first
designated contract address to a second designated contract
address. In embodiments, the fourth smart contract instructions
further include: (3) token destruction instructions related to
destroying one or more digital asset token. In embodiments, the
fourth smart contract instructions further include: (3) token
balance modification instructions related to modifying a total
number of tokens of the digital asset token assigned to a third
designated public address. In embodiments, the fourth smart
contract instructions further include: (3) token transfer
instructions related to transferring tokens of the digital asset
token from a first designated contract address to a second
designated contract address; and (4) token destruction instructions
related to destroying one or more tokens of the digital asset
token.
[0042] In embodiments, the method further includes receiving, prior
to generating the first amount of digital asset tokens, a
validating request. In embodiments, the method further includes
determining the first designated key set has authority to process
the request to generate the first amount of digital tokens.
[0043] In embodiments, the first transaction request includes first
transaction fee information for miners in the plurality of
geographically distributed computer systems in the peer-to-peer
network to process the first transaction request.
[0044] In embodiments, the fifth contract returns the balance of
digital asset tokens to the fourth smart contract address. In
embodiments, the fifth contract returns the balance of digital
asset tokens to the second smart contract address.
[0045] In embodiments, the method further includes the steps of:
(k) receiving, by the plurality of geographically distributed
computer systems in the peer-to-peer network, from a first user
device associated with the first designated public address, via the
underlying blockchain, a second transaction request: (A) from the
first designated public address; (B) to the first contract address;
and (C) including a second message including a second request to
transfer a fifth amount of digital assets from the first designated
public address to a third designated public address; wherein the
first transaction request is digitally signed by the first
designated private key, which is mathematically related to the
first designated public address; wherein the first user device had
access to the first designated private key prior to sending the
second transaction request; wherein the first smart contract
executes, via the plurality of geographically distributed computer
systems in the peer-to-peer network, the second transaction request
to execute, via the plurality of geographically distributed
computer systems in the peer-to-peer network, a sixth call request
to the fourth contract address to transfer a fifth amount of
digital assets from the first designated public address to the
third designated public address; wherein, in response to the sixth
call request, the fourth smart contract, executes via the plurality
of geographically distributed computer systems in the peer-to-peer
network, sixth authorization instructions to verify the sixth call
came from an authorized contract address, and upon verification, to
execute a seventh call request to the fifth contract address to
obtain a sixth amount of digital asset tokens which reflect a
current balance of digital asset tokens associated with the first
designated public address; wherein, in response to the seventh call
request, the fifth smart contract, executes via the plurality of
geographically distributed computer systems in the peer-to-peer
network, the seventh call request to return the sixth amount of
digital asset tokens; wherein, in response to the return of the
sixth amount of digital asset, the fourth smart contract executes,
via the plurality of geographically distributed computer systems in
the peer-to-peer network: (1) a balance verification instruction to
confirm that the fifth amount of digital asset tokens is less than
or equal to the sixth amount of digital asset tokens, and (2) in
the case where the fifth amount of digital asset tokens is less
than or equal to the sixth amount of digital asset tokens, execute,
via the plurality of geographically distributed computer systems in
the peer-to-peer network, a seventh call request to the fifth
contract address to set a new balance for the digital asset tokens
in the first designated public address to a seventh amount which
equals the sixth amount less the fifth amount; wherein, in response
to the seventh call, the fifth smart contract executes, via the
plurality of geographically distributed computer systems in the
peer-to-peer network, the seventh call to set and store the new
balance for the first designated public address as the seventh
amount and returns a new balance for the first designated public
address as the seventh amount; wherein, in response to the return
of the new balance, the fourth smart contract executes, via the
plurality of geographically distributed computer systems in the
peer-to-peer network, an eighth call to add the second amount of
digital asset tokens to the balance associated with the third
designated public address; wherein, in response to the eighth call
request, the fifth smart contract executes, via the blockchain
network, the eighth call request to set the balance of digital
asset tokens associated with the third designated public address at
a seventh amount which includes the addition of the second amount
to a previous balance associated with the third designated public
address; and wherein the first user device confirms that the
balance of digital asset tokens associated with the first
designated public address is the sixth amount of digital asset
tokens based on reference to the blockchain.
[0046] In embodiments, the second transaction request includes
second transaction fee information for miners in the plurality of
geographically distributed computer systems in the peer-to-peer
network to process the second transaction request. In embodiments,
the balance of digital asset tokens associated with the third
designated public address is returned to the fourth contract
address. In embodiments, the balance of digital asset tokens
associated with the third public address is returned to the first
smart contract address. In embodiments, a second user device
confirms that the balance of the digital asset tokens associated
with the third designated public address is the seventh amount of
digital asset tokens based on reference to the blockchain.
[0047] In embodiments, the method further includes the steps of:
(k) providing a third designated key set, including a third
designated public address associated with the underlying digital
asset and a corresponding third designated private key, and wherein
the third designated private key is stored on a third computer
system which is connected to the distributed public transaction
ledger through the Internet; and (l) receiving, by the plurality of
geographically distributed computer systems in the peer-to-peer
network, from the third computer system, via the blockchain, a
second transaction request: (A) from the third designated public
key address; (B) to the fifth contract address; and (C) including a
second message including a request to burn a fifth amount of
digital asset tokens from a balance associated with the third
designated public address; wherein the second transaction request
is digitally signed by the third designated private key; wherein
the fourth smart contract executes, via the plurality of
geographically distributed computer systems in the peer-to-peer
network, the second transaction request to execute, via the
plurality of geographically distributed computer systems in the
peer-to-peer network, a sixth call request to the fifth contract
address to obtain a sixth amount of digital asset tokens which
reflect a current balance of digital asset tokens associated with
the third designated public address; wherein, in response to the
sixth call request, the fifth smart contract, executes via the
plurality of geographically distributed computer systems in the
peer-to-peer network, the seventh call request to return the sixth
amount of digital asset tokens; wherein, in response to the return
of the sixth amount of digital asset, the fourth smart contract
executes, via the plurality of geographically distributed computer
systems in the peer-to-peer network: (1) a balance verification
instruction to confirm that the fifth amount of digital asset
tokens is less than or equal to the sixth amount of digital asset
tokens; and (2) in the case where the fifth amount of digital asset
tokens is less than or equal to the sixth amount of digital asset
tokens, execute, via the plurality of geographically distributed
computer systems in the peer-to-peer network, a seventh call
request to the fifth contract address to set a new balance for the
digital asset tokens associated with the third designated public
key address to a seventh amount which equals the sixth amount less
the fifth amount; wherein, in response to the seventh call, the
fifth smart contract executes, via the plurality of geographically
distributed computer systems in the peer-to-peer network, the
seventh call to set and store the new balance for the third
designated public key address as the seventh amount and returns the
new balance for the third designated public key address as the
seventh amount; wherein, in response to the return of the new
balance, the fourth smart contract executes, via the blockchain
network, an eighth call request to the fifth contract address to
obtain a total supply of digital asset tokens in circulation;
wherein, in response to the eighth call request, the fifth smart
contract executes, via the plurality of geographically distributed
computer systems in the peer-to-peer network, the eighth call
request and returns, to the fourth contract address, an eighth
amount of digital asset tokens corresponding to the total supply of
digital asset tokens in circulation; wherein, in response to the
return of the eighth amount, the fourth smart contract, executes
via the plurality of geographically distributed computer systems in
the peer-to-peer network, a ninth call request to the fifth
contract address to set a new total supply of digital asset tokens
in circulation to a ninth amount, which is the eighth amount less
the fifth amount; and wherein, in response to the ninth call
request, the fifth smart contract, executes via the blockchain
network, the ninth call request and sets a new total supply of
digital asset tokens in circulation at the ninth amount, and
returns to the fourth contract address.
[0048] In embodiments, the third designated key set is the first
designated key set. In embodiments, the third designated key set is
not the second designated key set. In embodiments, the third
designated key set is the second designated key set. In
embodiments, the third designated key set is not the first
designated key set. In embodiments, the third computer system is
the first computer system. In embodiments, the third computer
system is not the first computer system. In embodiments, the
administrator computer system includes the first computer system
and the third computer system. In embodiments, the administrator
computer system includes the first computer system and the second
computer system.
[0049] In embodiments, the underlying digital asset is a stable
value token. In embodiments, the underlying digital asset is Neo.
In embodiments, the underlying digital asset is Ether. In
embodiments, the underlying digital asset is Bitcoin.
[0050] In embodiments, the first designated private key is
mathematically related to a first designated public key.
[0051] In embodiments, wherein the first designated public address
includes the first designated public key.
[0052] In embodiments, the first designated public address includes
a hash of the first designated public key.
[0053] In embodiments, the first designated public address includes
a partial hash of the first designated public key.
[0054] In embodiments, the second designated private key is
mathematically related to a second designated public key.
[0055] In embodiments, the second designated public address
includes the second designated public key.
[0056] In embodiments, the second designated public address
includes a hash of the second designated public key.
[0057] In embodiments, the second designated public address
includes a partial hash of the second designated public key.
[0058] In embodiments, the second smart contract instructions
include sixth authorization instructions related to modifying a
token supply of the digital asset token.
[0059] A method of increasing a total supply of digital asset
tokens includes in accordance with an embodiment of the present
application includes the steps of:(a) providing a first designated
key pair, comprising a first designated public key of an underlying
digital asset and a corresponding first designated private key,
wherein the underlying digital asset is maintained on a distributed
public transaction ledger maintained by a plurality of
geographically distributed computer systems in a peer-to-peer
network in the form of a blockchain, and wherein the first
designated private key is stored on a first computer system which
is connected to the distributed public transaction ledger through
the Internet; (b)providing a second designated key pair, comprising
a second designated public key of the underlying digital asset and
a corresponding second designated private key, wherein the second
designated private key is stored on a second computer system which
is physically separated from the first computer system and is not
operatively or physically connected to the distributed public
transaction ledger or the Internet; (c) providing first smart
contract instructions for a digital asset token associated with a
first contract address associated with the blockchain associated
with the underlying digital asset, wherein the first smart contract
instructions are saved in the blockchain for the underlying digital
assets and include: (1) first delegation instructions to delegate
one or more first functions associated with the digital asset token
to one or more delegated contract addresses associated with the
blockchain associated with the underlying digital asset, wherein
the one or more delegated contract addresses is different from the
first contract address; (2) first authorization instructions for
the second designated key pair; (d) providing second smart contract
instructions for the digital asset token associated with a second
contract address associated with the blockchain associated with the
underlying digital asset, which is one of the one or more delegated
contract addresses and not the first contract address, wherein the
second smart contract instructions are saved in the blockchain for
the underlying digital assets and include: (1) print limiter token
creation instructions indicating conditions under which tokens of
the digital asset token are created; (2) second authorization
instructions for the first designated key pair with respect to
token creation of the digital asset token; (3) third authorization
instructions for a first designated custodian address with respect
to token creation of the digital asset token; (e) providing third
smart contract instructions for the digital asset token associated
with a third contract address associated with the blockchain
associated with the underlying digital asset, which is the first
designated custodian contract address, wherein the third smart
contract instructions are saved in the blockchain for the
underlying digital assets and include: (1) fourth authorization
instructions for the second designated key pair with respect to
authorizing the issuance of instructions to the second smart
contract regarding token creation; (f) providing fourth smart
contract instructions for the digital asset token associated with a
fourth contract address associated with the blockchain associated
with the underlying digital asset, which is one of the one or more
delegated contract addresses and not the first contract address,
second contract address or third contract address, wherein the
fourth smart contract instructions are saved in the blockchain for
the underlying digital assets and include: (1) token creation
instructions to create tokens of the digital asset tokens under
conditions set forth by the print limiter token creation
instructions; (2) second delegation instructions for delegating to
another contract address, data storage operations; (g) providing
fifth smart contract instructions for the digital asset token
associated with a fifth contract address associated with the
blockchain associated with the underlying digital asset, which is
one of the one or more designated store contract addresses, wherein
the fifth smart contract instructions are saved in the blockchain
for the underlying digital assets and include: (1) data storage
instructions for transaction data related to the digital asset
token, wherein said transaction data comprises for all issued
tokens of the digital asset token: (A) public address information
associated with the underlying digital asset; and (B) corresponding
token balance information associated with said public address
information; (2) fifth authorization instructions for modifying the
transaction data in response to a request from the fourth contract
address; (h) increasing the total supply of the digital asset
token, by a digital asset token issuer system, from a first amount
of the digital asset tokens to a second amount of the digital asset
tokens, comprising the steps of: (1) generating, by the digital
asset token issuer system, a first transaction request including a
first message comprising a first request to increase the total
supply of the digital asset token to a second amount of digital
asset tokens, from the on-line public key address to the fourth
contract address, wherein the first transaction request is
digitally signed by the first on-line private key; (2) sending, by
the digital asset token issuer system via the underlying
blockchain, the first transaction request from the on-line public
key address to the fourth contract address; (3) sending, by the
digital asset token issuer system via the underlying blockchain,
the first transaction request from the fourth contract address to
the second contract address; wherein the second smart contract
executes, via the blockchain network, the first transaction request
to return a first unique lock identifier associated with the first
transaction request; (4) obtaining, by the digital asset token
issuer system, the first unique lock identifier, based on reference
to the blockchain; (5) generating, by the digital asset token
issuer system, a second transaction request including a second
message comprising a second request to unlock the total supply of
the digital asset token in accordance with the first request and
including the first unique lock identifier, the second transaction
request being from the on-line public key address to the third
contract address, wherein the second transaction request is
digitally signed by the first on-line private key; (6) sending, by
the digital asset token issuer system via the underlying
blockchain, the second transaction request from the on-line public
key address to the third contract address; wherein the third smart
contract executes, via the blockchain network, the second
transaction request to return a first unique request hash
associated with the second transaction request; (7) obtaining, by
the digital asset token issuer system, the first unique request
hash, based on reference to the blockchain; (8) generating, by the
digital asset token issuer system, a third transaction request to
be digitally signed by at least the second designated private key
including the first unique request hash; (9) transferring, from the
digital asset token issuer system to a first portable memory
device, the third transaction request; (10) transferring, from the
first portable memory device to the second computer system, the
third transaction request; (11) digitally signing, by the second
computer system, the third transaction request using the second
designated private key to generate a third digitally signed
transaction request; (12) sending, from the second portable memory
device using the digital asset token issuer system, via the
underlying blockchain, the third digitally signed transaction
request to the third contract address; and (i) confirming, by the
digital asset token issuer system, that the total supply of digital
asset tokens is set to the second amount of digital asset tokens
based on reference to the blockchain; wherein the third smart
contract, executes, via the blockchain network, the third digitally
signed transaction request to validate the second request to unlock
based on the third digitally signed transaction request and the
first unique request hash and executes a first call to the second
contract address, to increase the total supply of the digital asset
token to the second amount of digital asset tokens, wherein the
second contract address returns the first call to the fourth
contract address and the fourth smart contract executes, via the
blockchain network, a second call to the fifth contract address to
set the total supply of the digital asset tokens to the second
amount of digital asset tokens, wherein the fifth smart contract
executes, via the blockchain, the second call to set the total
supply of the digital asset tokens to the second amount of digital
asset tokens.
[0060] In embodiments, the first designated key pair includes an
additional designated key pair comprising an additional designated
public key and an additional designated private key.
[0061] In embodiments, the second computer system is a hardware
storage module.
[0062] In embodiments, the second designated key pair comprises an
additional designated key pair comprising an additional designated
public key and an additional designated private key.
[0063] In embodiments, the second authorization instructions for
the first designated key pair with respect to token creation of the
digital asset token includes instructions limiting creation of
digital asset tokens above a first threshold amount over a first
period of time.
[0064] In embodiments, the fourth authorization instructions for
the second designated key pair to authorize the issuance of
instructions to the second smart contract instructions with respect
to token creation includes instructions to permit creation of
digital asset tokens above the first threshold during the first
period of time.
[0065] In embodiments, the third smart contract instructions
further include: (2) sixth authorization instructions for the
second designated key pair to authorize the issuance of
instructions, to the first smart contract, to change the one or
more designated contract addresses from the second contract address
to a different designated contract address.
[0066] In embodiments, the fourth smart contract instructions
further include: (3) token transfer instructions related to
transferring tokens of the digital asset token from a first
designated contract address to a second designated contract
address.
[0067] In embodiments, the fourth smart contract instructions
further include: (3) token destruction instructions related to
destroying one or more tokens of the digital asset token.
[0068] In embodiments, the second smart contract instructions
further include: (4) token balance modification instructions
related to modifying a total number of tokens of the digital asset
token assigned to a third designated address.
[0069] In embodiments, the fourth smart contract instructions
further include: (3) token transfer instructions related to
transferring tokens of the digital asset token from a first
designated contract address to a second designated contract
address; and (4) token destruction instructions related to
destroying one or more tokens of the digital asset token.
[0070] In embodiments, the first transaction request includes first
transaction fee information for miners in the blockchain network to
process the first transaction request.
[0071] In embodiments, the second transaction request includes
second transaction fee information for miners in the blockchain
network to process the second transaction request.
[0072] In embodiments, the first portable memory device includes
the second portable memory device.
[0073] In embodiments, the second smart contract instructions
include sixth authorization instructions related to modifying a
token supply amount of the digital asset token.
[0074] A method of increasing a total supply of digital asset
tokens in accordance with an embodiment of the present application
includes the steps of: (a) providing a first designated key pair,
comprising a first designated public key of an underlying digital
asset and a corresponding first designated private key, wherein the
underlying digital asset is maintained on a distributed public
transaction ledger maintained by a plurality of geographically
distributed computer systems in a peer-to-peer network in the form
of the blockchain, and wherein the first designated private key is
stored on a first computer system which is connected to the
distributed public transaction ledger through the Internet; (b)
providing a second designated key pair, comprising a second
designated public key of the underlying digital asset and a
corresponding second designated private key, wherein the second
designated private key is stored on a second computer system which
is physically separated from the first computer system and is not
operatively or physically connected to the distributed public
transaction ledger or the Internet; (c) providing first smart
contract instructions for a digital asset token associated with a
first contract address associated with the blockchain associated
with the underlying digital asset, wherein the first smart contract
instructions are saved in the blockchain for the underlying digital
assets and include: (1) first delegation instructions to delegate
one or more first functions associated with the digital asset token
to one or more delegated contract addresses associated with the
blockchain associated with the underlying digital asset, wherein
the one or more delegated contract addresses is different from the
first contract address; and (2) first authorization instructions
for the second designated key pair; (d) providing second smart
contract instructions for the digital asset token associated with a
second contract address associated with the blockchain associated
with the underlying digital asset, which is one of the one or more
delegated contract addresses and not the first contract address,
wherein the second smart contract instructions are saved in the
blockchain for the underlying digital assets and include: (1) print
limiter token creation instructions indicating conditions under
which tokens of the digital asset token are created; (2) first
custodian address information instructions associated with a first
designated custodian; and (3) second authorization instructions for
the first designated key pair with respect to token creation of the
digital asset token; (e) providing third smart contract
instructions for the digital asset token associated with a third
contract address associated with the blockchain associated with the
underlying digital asset, which is the first designated custodian
contract address, wherein the third smart contract instructions are
saved in the blockchain for the underlying digital assets and
include: (1) fourth authorization instructions for the second
designated key pair with respect to issuance of instructions to the
second smart contract regarding token creation; (f) providing
fourth smart contract instructions for the digital asset token
associated with a fourth contract address associated with the
blockchain associated with the underlying digital asset, wherein
the fourth smart contract instructions are saved in the blockchain
for the underlying digital assets and include: (1) token creation
instructions related to creating tokens of the digital asset token
under the conditions set forth by the print limiter token creation
instructions; and (2) second delegation instructions for delegating
to one or more designated store contract addresses data storage
functions; (g) providing fifth smart contract instructions for the
digital asset token associated with a fifth contract address
associated with the blockchain associated with the underlying
digital asset, which is one of the one or more designated stored
contract addresses, wherein the fifth smart contract instructions
are saved in the blockchain for the underlying digital assets and
include: (1) data storage instructions for transaction data related
to the digital asset token, wherein said transaction data comprises
for all issued tokens of the digital asset token: (A) public
address information associated with the underlying digital asset;
and (B) corresponding token balance information associated with
said public address information; (2) third custodian instructions
associated with a third designated custodian address corresponding
to the fourth contracts address; and (3) fifth authorization
instruction for modifying the transaction data in response to
requests from the fourth contract address; (h) receiving, by the
digital asset token issuer system, a request to generate and assign
to a first designated public address a first amount of digital
tokens; (i) generating, by a digital asset token issuer system, the
first amount of digital asset tokens and assigning said first
amount of digital asset token to the first designated public
address increasing the total supply of the digital asset token,
comprising the steps of: (1) generating, by the digital asset token
issuer system, and sending, from the digital asset token issuer
system via the underlying blockchain, a first transaction request:
(A) from the on-line public key address; (B) to the fourth contract
address; and (C) including a first message comprising a first
request to generate the first amount of digital asset token and
assign said first amount of digital asset tokens to the first
designated public address; wherein the first transaction request is
digitally signed by the first on-line private key; wherein the
fourth smart contract executes, via the blockchain network, the
first transaction request to: (i) validate the first request and
the authority of the first on-line private key to call the second
smart contract to execute the first request; and (ii) send a first
call to the fourth contract address to generate and assign to the
first designated public address the first amount of digital asset
tokens; wherein the fourth smart contract executes, via the
blockchain network, the first call request to generate a first
unique lock identifier, and return to the second smart contract
address the first unique lock identifier; wherein, in response to
the return of the first unique lock identifier, the second smart
contract executes, via the blockchain network, a call to the fourth
smart contract address to confirm the first call request with the
first lock identifier; wherein, in response, the fourth smart
contract executes, via the blockchain network, the first call to
execute a second call to the fifth contract address to obtain the
total supply of digital asset tokens in circulation; wherein, in
response, the fifth smart contract executes, via the blockchain
network, the second call and returns, to the fourth contract
address, a second amount of digital asset tokens corresponding to
the total supply of digital asset tokens in circulation; wherein,
in response to the return of the second amount, the fourth smart
contract, executes via the blockchain network, a third call request
to the fifth contract address to set a new total supply of digital
asset tokens in circulation to a third amount, which is the total
of the first amount and the second amount; wherein, in response to
the third call, the fifth smart contract, executes via the
blockchain network, the third call and sets a new total supply of
digital asset tokens in circulation at the third amount; wherein,
the fourth smart contract executes, via the blockchain network, a
fourth call to the fifth contract address to add the first amount
of digital asset tokens to the balance associated with the first
designated public address; wherein, in response the fifth smart
contract executes, via the blockchain network, the fourth call to
set the balance of digital asset tokens in the first designated
public address at a fourth amount which includes the addition of
the first amount to the previous balance; and (j)
[0075] confirming, by the digital asset token issuer system, that
the balance of digital asset tokens in the first designated public
address is set to include the first amount of digital asset tokens
based on reference to the blockchain.
[0076] In embodiments, the second computer system is a hardware
storage module.
[0077] In embodiments, the second designated key pair comprises an
additional designated key pair comprising an additional designated
public key and an additional designated private key.
[0078] In embodiments, the second authorization instructions for
the first designated key pair with respect to token creation of the
digital asset token include instruction limiting token creation
above a first threshold over a first period of time.
[0079] In embodiments, the fourth authorization instructions for
the second designated key pair to authorize the issuance of
instructions to the second smart contract instructions with respect
to token creation include instructions to allow for creation of
digital asset tokens above the first threshold during the first
period of time.
[0080] In embodiments, the third smart contract instructions
further include: (2) sixth authorization instructions for the
second designated key pair to authorize the issuance of
instructions to the first smart contract to change the one or more
designated contract addresses from the second contract address to a
different designated contract address.
[0081] In embodiments, the fourth smart contract instructions
further include: (3) token transfer instructions related to
transferring tokens of the digital asset token from a first
designated contract address to a second designated contract
address.
[0082] In embodiments, the fourth smart contract instructions
further include: (3) token destruction instructions related to
destroying one or more digital asset token.
[0083] In embodiments, the fourth smart contract instructions
further include: (3) token balance modification instructions
related to modifying a total number of tokens of the digital asset
token assigned to a third designated address.
[0084] In embodiments, the fourth smart contract instructions
further include: (3) token transfer instructions related to
transferring tokens of the digital asset token from a first
designated contract address to a second designated contract
address; and (4) token destruction instructions related to
destroying one or more tokens of the digital asset token.
[0085] In embodiments, the method further comprises receiving,
prior to generating the first amount of digital asset tokens, a
validating request.
[0086] In embodiments, the method further comprises determining the
first designated key pair has authority to process the request to
generate the first amount of digital tokens.
[0087] In embodiments, the first transaction request includes first
transaction fee information for miners in the blockchain network to
process the first transaction request.
[0088] In embodiments, the fifth contract returns the balance of
digital asset tokens to the fourth smart contract address.
[0089] In embodiments, the fifth contract returns the balance of
digital asset tokens to the second smart contract address.
[0090] In embodiments, the method further comprises the steps of:
(k) receiving, by the blockchain network, from a first user device
associated with the first designated public address, via the
underlying blockchain, a second transaction request: (A) from the
first designated public address; (B) to the first contract address;
and (C) including a second message comprising a second request to
transfer a fifth amount of digital assets from the first designated
public address to a second designated public address; wherein the
first transaction request is digitally signed by a first private
key, which is mathematically related to the first designated public
address, and wherein the first user device had access to the first
private key prior to sending the second transaction request; and
wherein the first smart contract executes, via the blockchain
network, the second transaction request to execute, via the
blockchain network, a sixth call request to fourth contract address
to transfer a fifth amount of digital assets from the first
designated public address to the second designated public address;
wherein, in response to the sixth call request, the fourth smart
contract, executes via the blockchain network, sixth authorization
instructions to verify the sixth call came from an authorized
contract address, and upon verification, to execute a seventh call
request to the fifth contract address to obtain a sixth amount of
digital asset tokens which reflect a current balance of digital
asset tokens associated with the first designated public address;
wherein, in response to the seventh call request, the fifth smart
contract, executes via the blockchain network, the seventh call
request to return the sixth amount of digital asset tokens;
wherein, in response to the return of the sixth amount of digital
asset, the fourth smart contract executes, via the blockchain
network: (1) a balance verification instruction to confirm that the
fifth amount of digital asset tokens is less than or equal to the
sixth amount of digital asset tokens, and (2) in the case where the
fifth amount of digital asset tokens is less than or equal to the
sixth amount of digital asset tokens, execute, via the blockchain
network, a seventh call request to the fifth contract address to
set a new balance for the digital asset tokens in the first
designated public address to a seventh amount which equals the
sixth amount less the fifth amount; wherein, in response to the
seventh call, the fifth smart contract executes, via the blockchain
network, the seventh call to set and store the new balance for the
first designated public address as the seventh amount and returns a
new balance for the first designated public address as the seventh
amount; wherein, in response to the return of the new balance, the
fourth smart contract executes, via the blockchain network, an
eighth call to add the second amount of digital asset tokens to the
balance associated with the second designated public address;
wherein, in response to the eighth call request, the fifth smart
contract executes, via the blockchain network, the eighth call
request to set the balance of digital asset tokens in the second
designated public address at a seventh amount which includes the
addition of the second amount to a previous balance associated with
the second designated public address; and wherein the first user
device confirms that the balance of digital asset tokens in the
first designated public address is the sixth amount of digital
asset tokens based on reference to the blockchain.
[0091] In embodiments, the second transaction request includes
second transaction fee information for miners in the blockchain
network to process the second transaction request.
[0092] In embodiments, the balance of digital asset tokens in the
second designated public address is returned to the fourth contract
address.
[0093] In embodiments, the balance of digital asset tokens in the
second public address is returned to the first smart contract
address.
[0094] In embodiments, a second user device confirms that the
balance of the digital asset tokens in the second designated public
address is the seventh amount of digital asset tokens based on
reference to the blockchain.
[0095] In embodiments, the method further includes the steps of:
(k) providing a third designated key pair, comprising a third
designated public key of the underlying digital asset and a
corresponding third designated private key, and wherein the third
designated private key is stored on a third computer system which
is connected to the distributed public transaction ledger through
the Internet; (l) receiving, by the blockchain network, from the
third computer system, via the underlying blockchain, a second
transaction request: (A) from the third designated public key
address; (B) to the fifth contract address; and (C) including a
second message comprising a request to burn a fifth amount of
digital asset tokens from a balance associated with the third
designated public key address; wherein the second transaction
request is digitally signed by a third designated private key;
wherein the fourth smart contract executes, via the blockchain
network, the second transaction request to execute, via the
blockchain network, a sixth call request to the fifth contract
address to obtain a sixth amount of digital asset tokens which
reflect a current balance of digital asset tokens associated with
the third designated public key address; wherein, in response to
the sixth call request, the fifth smart contract, executes via the
blockchain network, the seventh call request to return the sixth
amount of digital asset tokens; wherein, in response to the return
of the sixth amount of digital asset, the fourth smart contract
executes, via the blockchain network: (1) a balance verification
instruction to confirm that the fifth amount of digital asset
tokens is less than or equal to the sixth amount of digital asset
tokens; and (2) in the case where the fifth amount of digital asset
tokens is less than or equal to the sixth amount of digital asset
tokens, execute, via the blockchain network, a seventh call request
to the fifth contract address to set a new balance for the digital
asset tokens in the third designated public key address to a
seventh amount which equals the sixth amount less the fifth amount;
wherein, in response to the seventh call, the fifth smart contract
executes, via the blockchain network, the seventh call to set and
store the new balance for the third designated public key address
as the seventh amount and returns the new balance for the third
designated public key address as the seventh amount; wherein, in
response to the return of the new balance, the fourth smart
contract executes, via the blockchain network, an eighth call
request to the fifth contract address to obtain a total supply of
digital asset tokens in circulation; wherein, in response to the
eighth call request, the fifth smart contract executes, via the
blockchain network, the eighth call request and returns, to the
fourth contract address, an eighth amount of digital asset tokens
corresponding to the total supply of digital asset tokens in
circulation; wherein, in response to the return of the eighth
amount, the fourth smart contract, executes via the blockchain
network, a ninth call request to the fifth contract address to set
a new total supply of digital asset tokens in circulation to a
ninth amount, which is the eighth amount less the fifth amount; and
wherein, in response to the ninth call request, the fifth smart
contract, executes via the blockchain network, the ninth call
request and sets a new total supply of digital asset tokens in
circulation at the ninth amount, and returns to the fourth contract
address.
[0096] In embodiments, the third designated key pair is the first
designated key pair.
[0097] In embodiments, the third designated key pair is not the
second designated key pair.
[0098] In embodiments, the third designated key pair is the second
designated key pair.
[0099] In embodiments, the third designated key pair is not the
first designated key pair.
[0100] In embodiments, the third computer system is the first
computer system.
[0101] In embodiments, the third computer system is not the first
computer system.
[0102] In embodiments, the administrator computer system comprises
the first computer system and the third computer system.
[0103] In embodiments, the administrator computer system comprises
the first computer system and the second computer system.
[0104] In embodiments, the second smart contract instructions
include sixth authorization instructions related to modifying a
token supply of the digital asset token.
BRIEF DESCRIPTION OF THE DRAWINGS
[0105] Exemplary embodiments of the present invention will be
described with references to the accompanying figures, wherein:
[0106] FIG. 1 is a schematic diagram of a digital asset network in
accordance with exemplary embodiments of the present invention;
[0107] FIG. 2 is an exemplary screen shot of an excerpt of an
exemplary bitcoin transaction log showing digital addresses in
accordance with exemplary embodiments of the present invention;
[0108] FIG. 2A is an exemplary screen shot of a Security Token
ledger in accordance with exemplary embodiments of the present
invention;
[0109] FIG. 3 is an exemplary exchange agent interface in
accordance with exemplary embodiments of the present invention;
[0110] FIGS. 4A-4B are exemplary schematic diagrams illustrating
participants in a digital asset exchange in accordance with
exemplary embodiments of the present invention;
[0111] FIGS. 5A-5B are schematic diagrams of exemplary exchange
computer systems in accordance with exemplary embodiments of the
present invention;
[0112] FIG. 6 is an exemplary flow chart for processes for digital
asset exchange account creation and account funding in accordance
with exemplary embodiments of the present invention;
[0113] FIGS. 7A-7B are an exemplary schematic diagram and a
corresponding flow chart of a process for digital asset exchange
customer account fiat funding via an exchange-initiated request in
accordance with exemplary embodiments of the present invention;
[0114] FIGS. 7C-7E are an exemplary schematic diagram and a
corresponding flow chart of a process for digital asset exchange
customer account fiat funding via a customer-initiated request in
accordance with exemplary embodiments of the present invention;
[0115] FIGS. 8A-8B are an exemplary schematic diagram and a
corresponding flow chart of a process for digital asset exchange
account digital asset withdrawal in accordance with exemplary
embodiments of the present invention;
[0116] FIG. 9A is an exemplary flow chart of the process for
purchasing SVCoin for fiat on a digital asset exchange in
accordance with exemplary embodiments of the present invention;
[0117] FIG. 9B is an exemplary flow chart of the process for
redeeming SVCoin for fiat on a digital asset exchange in accordance
with exemplary embodiments of the present invention;
[0118] FIG. 10 is an exemplary flow chart of the process of sending
tokens from Alice to Bob on the Ethereum blockchain in accordance
with exemplary embodiments of the present invention;
[0119] FIGS. 11A-1-11A-4 illustrate an exemplary embodiment of a
dashboard fiat interface which allows registered users to deposit
and/or withdraw fiat with the digital asset exchange in accordance
with exemplary embodiments of the present invention;
[0120] FIGS. 11B-1-11B-4 illustrate an exemplary dashboard digital
asset interface which allows registered users to deposit and/or
withdrawal digital assets with the digital asset exchange system in
accordance with exemplary embodiments of the present invention;
[0121] FIGS. 11C-1-11C-2 illustrate an exemplary dashboard SVCoin
interface which allows registered users to purchase and/or redeem
SVCoins for fiat or digital with the digital asset exchange system
in accordance with exemplary embodiments of the present
invention;
[0122] FIG. 11D illustrates an exemplary dashboard Security Token
interface which allow Security Token issuers to provide
instructions to transfer SVCoins to Security Token holders in
accordance with exemplary embodiments of the present invention;
[0123] FIG. 12 illustrates an exemplary flow reflecting an
exemplary embodiment where a Security Token issuer initiates a
transfer of SVCoins to Security Token holders in accordance with
exemplary embodiments of the present invention;
[0124] FIGS. 13A-13H illustrate exemplary embodiments of a token
that utilizes smart contracts in accordance with exemplary
embodiments of the present invention;
[0125] FIGS. 14A-14G illustrate an exemplary process flow chart of
a process reflecting an exemplary embodiment of a method of issuing
a stable value digital asset token in accordance with exemplary
embodiments of the present invention;
[0126] FIGS. 15A-15C illustrate an exemplary dashboard of a user
interface which allows registered users of a digital asset exchange
to deposit and/or withdraw SVCoins (referred to as Gemini Dollars)
with the digital asset exchange system in accordance with exemplary
embodiments of the present invention;
[0127] FIG. 16A is an exemplary flowchart of a process for
withdrawing stable value digital asset tokens from a digital asset
exchange computer system in accordance with exemplary embodiments
in the present invention;
[0128] FIG. 16B is an exemplary flowchart of a process for
authenticating an access request by a user device in accordance
with exemplary embodiments in the present invention;
[0129] FIG. 16C is an exemplary flowchart of a process for
obtaining a withdraw request in accordance with exemplary
embodiments in the present invention;
[0130] FIGS. 16D-16E are exemplary flowcharts of a process for
processing a withdraw request in accordance with exemplary
embodiments in the present invention;
[0131] FIG. 17A is an exemplary flowchart of a process for
depositing stable value digital asset tokens in accordance with
exemplary embodiments in the present invention;
[0132] FIG. 17B is an exemplary flowchart of a process for
authenticating an access request by a user device in accordance
with exemplary embodiments in the present invention;
[0133] FIG. 17C is an exemplary flowchart of a process for
obtaining a deposit request in accordance with exemplary
embodiments in the present invention;
[0134] FIGS. 17D-17E are exemplary flowcharts of a process for
processing a deposit request in accordance with exemplary
embodiments in the present invention;
[0135] FIG. 18A is a schematic drawing of an exemplary collection
of systems for increasing the total supply of digital asset tokens
on an underlying blockchain in accordance with exemplary
embodiments of the present invention;
[0136] FIG. 18B is a schematic drawing of an exemplary proxy smart
contract in accordance with exemplary embodiments of the present
invention;
[0137] FIG. 18C is a schematic drawing of an exemplary print
limiter contract in accordance with exemplary embodiments of the
present invention;
[0138] FIG. 18D is a schematic drawing of an exemplary custodian
smart contract in accordance with exemplary embodiments of the
present invention;
[0139] FIG. 18E is a schematic drawing of a store smart contract in
accordance with exemplary embodiments of the present invention;
[0140] FIG. 18F is a schematic drawing of an impl smart contract in
accordance with exemplary embodiments of the present invention;
[0141] FIG. 19A is a schematic drawing of an exemplary process for
increasing the ceiling of a print limiter in accordance with
exemplary embodiments of the present invention;
[0142] FIG. 19B is a schematic drawing of an exemplary process for
increasing the ceiling of a print limiter in accordance with
exemplary embodiments of the present invention;
[0143] FIG. 19C is a schematic drawing of an exemplary process of
limiting the print limiter with respect to a public address in
accordance with exemplary embodiments of the present invention;
[0144] FIG. 19D is a schematic drawing of an exemplary process of a
transfer request in accordance with exemplary embodiments of the
present invention;
[0145] FIG. 19E is a schematic drawing of an exemplary process of a
burn request in accordance with exemplary embodiments of the
present invention;
[0146] FIG. 20A is a flowchart of an exemplary process of
increasing a supply of tokens of a digital asset token using
off-line keys in accordance with exemplary embodiments of the
present invention;
[0147] FIG. 20A-1 is a flowchart of an exemplary process of
increasing the total supply of tokens of a digital asset token
using off-line keys in accordance with exemplary embodiments of the
present invention;
[0148] FIG. 20B is another flowchart of an exemplary process of
increasing the total supply of tokens of a digital asset token in
accordance with exemplary embodiments of the present invention;
[0149] FIG. 20C is another flowchart of an exemplary process of
increasing the total supply of tokens of a digital asset token in
accordance with exemplary embodiments of the present invention;
[0150] FIG. 21A is a flowchart of an exemplary process of
increasing the total supply of tokens of a digital asset token in
accordance with exemplary embodiments of the present invention;
[0151] FIG. 21B is a flowchart of an exemplary process of
increasing the total supply of tokens of a digital asset token in
accordance with exemplary embodiments of the present invention;
[0152] FIGS. 22A-22B are schematic diagrams illustrating
participants in a digital asset exchange in accordance with
exemplary embodiments of the present invention;
[0153] FIG. 23 is an exemplary flow chart for a process for
converting from, to or between digital assets in accordance with
exemplary embodiments of the present invention;
[0154] FIG. 24 is a schematic drawing of an exemplary network for
holding collateral in a smart contract on an underlying blockchain
in accordance with exemplary embodiments of the present
invention;
[0155] FIG. 25A is a schematic drawing of a contract parameters
database of a smart contract in accordance with exemplary
embodiments of the present invention;
[0156] FIG. 25B is a schematic drawing of data structures
associated with an exemplary security token on an underlying
blockchain including smart contract instruction modules in
accordance with exemplary embodiments of the present invention;
[0157] FIG. 25C is a schematic drawing of data structures
associated with an exemplary stable value token (SVCoin Token)
including smart contract instruction modules in accordance with
exemplary embodiments of the present invention;
[0158] FIG. 26A is a flow chart of a processes for holding
collateral for a security token in the form of a stable value token
in a smart contract on an underlying blockchain in accordance with
exemplary embodiments of the present invention;
[0159] FIGS. 26B-26C are flowcharts of an exemplary sub-process of
setting up a trade between a first user and a second user in
accordance with exemplary embodiments of the present invention;
[0160] FIG. 26D is a flowchart of another exemplary sub-process of
setting up a trade between a first user and a second user in
accordance with another exemplary embodiment of the present
invention;
[0161] FIG. 26E is a flowchart of an exemplary sub-process of
collecting excess collateral from a first user or a second user in
a trade in accordance with exemplary embodiments;
[0162] FIG. 26F is a flowchart of another exemplary sub-process of
collecting excess collateral from a first user and a second user in
a trade in accordance with exemplary embodiments;
[0163] FIGS. 27A-27B are exemplary graphical user interfaces (GUIs)
showing exemplary published contracts in accordance with exemplary
embodiments;
[0164] FIGS. 27C-27D are exemplary GUIs showing exemplary first
indications of interest from user Alice in accordance with
exemplary embodiments;
[0165] FIGS. 27E-27F are exemplary GUIs showing exemplary second
indications of interest from user Bob in accordance with exemplary
embodiments;
[0166] FIG. 28 is a flow chart of a processes for generating a
smart contract on an underlying blockchain in accordance with
exemplary embodiments of the present invention;
[0167] FIGS. 29A-29D are exemplary block diagrams of components of
security systems for an ETP holding digital math-based assets in
accordance with various exemplary embodiments of the present
invention;
[0168] FIGS. 30A-30D are exemplary block diagrams of components of
security systems for an exchange holding digital math-based assets
in accordance with various exemplary embodiments of the present
invention;
[0169] FIGS. 31A-31D are schematic diagrams of cold storage vault
systems in accordance with exemplary embodiments of the present
invention;
[0170] FIGS. 32A-32B are flow charts of exemplary processes for
creating and securing digital wallets in accordance with exemplary
embodiments of the present invention;
[0171] FIGS. 33A-33D are flow charts of exemplary processes for
generating digital asset accounts and securely storing the keys
corresponding to each account in accordance with exemplary
embodiments of the present invention;
[0172] FIG. 34 is a flow chart of an exemplary process for
retrieving securely stored keys associated with a digital asset
account in accordance with exemplary embodiments of the present
invention;
[0173] FIG. 35 is a flow chart of a method of performing a secure
transaction in accordance with exemplary embodiments of the present
invention;
[0174] FIGS. 36A-36B are schematic diagrams of vault arrangements
for a digital asset network in accordance with exemplary
embodiments of the present invention;
[0175] FIGS. 37A-37B are flow charts of processes for generating
key storage and insurance in accordance with exemplary embodiments
of the present invention;
[0176] FIGS. 38A-38C are flow charts of processes for recovering
key segments in accordance with exemplary embodiments of the
present invention; and
[0177] FIGS. 39A-39E are flow charts of processes for increasing a
total supply of digital asset tokens in accordance with exemplary
embodiments of the present invention.
DETAILED DESCRIPTION
[0178] The present invention generally relates to a system, method
and program product for the generating and distribution of a stable
value digital asset token tied to an underlying blockchain.
Digital Math-Based Assets and Bitcoin
[0179] A digital math-based asset is a kind of digital asset based
upon a computer generated mathematical and/or cryptographic
protocol that may, among other things, be exchanged for value
and/or be used to buy and sell goods or services. A digital
math-based asset may be a non-tangible asset that is not based upon
a governmental rule, law, regulation, and/or backing. The Bitcoin
system represents one form of digital math-based asset. The
Ethereum system represents another form of digital math-based
asset, which allows for smart contracts, as discussed below.
[0180] A bitcoin may be a unit of the Bitcoin digital math-based
asset. An ether may be a unit of the Ethereum digital math-based
asset.
[0181] Other examples of digital math-based assets include Bitcoin,
Ethereum, Ripple, Cardano, Litecoin, NEO, Stellar, IOTA, NEM, Dash,
Monero, Lisk, Qtum, Zcash, Nano, Steem, Bytecoin, Verge, Siacoin,
Stratis, BitShares, Dogecoin, Waves, Decred, Ardor, Hshare, Komodo,
Electroneum, Ark, DigiByte, E-coin, ZClassic, Byteball Bytes, PIVX,
Cryptonex, GXShares, Syscoin, Bitcore, Factom, MonaCoin, ZCoin,
SmartCash, Particl, Nxt, ReddCoin, Emercoin, Experience Points,
Neblio, Nexus, Blocknet, GameCredits, DigitalNote, Vertcoin,
BitcoinDark, Bitcoin Cash, Skycoin, ZenCash, NAV Coin, Achain,
HTMLCOIN, Ubiq, BridgeCoin, Peercoin, PACcoin, XTRABYTES,
Einsteinium, Asch, Counterparty, BitBay, Viacoin, Rise, Guiden,
ION, Metaverse ETP, LBRY Credits, Crown, Electra, Burst, MinexCoin,
Aeon, SaluS, DECENT, CloakCoin, Pura, ECC, DeepOnion, Groesticoin,
Lykke, Steem Dollars, I/O Coin, Shift, HempCoin, Mooncoin,
Dimecoin, Namecoin, Feathercoin, Diamond, Spectrecoin, Filecoin,
Tezos, PPCoin, Tonal bitcoin, IxCoin, Devcoin, Freicoin, I0coin,
Terracoin, Liquidcoin, BBQcoin, BitBars, Gas, Tether, Ether Classic
and PhenixCoin, to name a few. In embodiments, digital math-based
assets, such as bitcoin, may be accepted in trade by merchants,
other businesses, and/or individuals in many parts of the
world.
[0182] Digital assets may also include "tokens," which like other
digital assets can represent anything from loyalty points to
vouchers and IOUs to actual objects in the physical world. Tokens
can also be tools, such as in-game items, for interacting with
other smart contracts. A token is a "smart contract" running on top
of a blockchain network (such as the Ethereum Blockchain, the
Bitcoin Blockchain, to name a few). As such, it is a set of code
with an associated database. In embodiments, the database may be
maintained by an issuer. The code describes the behavior of the
token, and the database is basically a table with rows and columns
tracking who owns how many tokens.
[0183] In embodiments, a smart contract may be a computer protocol
intended to digitally facilitate, verify, or enforce the
negotiation or performance of credible transactions without third
parties. In embodiments, smart contracts may also allow for the
creation of tokens.
[0184] In embodiments, a digital math-based asset may be based on
an open source mathematical and/or cryptographic protocol, which
may exist on a digital asset network, such as a Bitcoin network or
an Ethereum network. The network may be centralized (e.g., run by
one or more central servers) or decentralized (e.g., run through a
peer-to-peer network). Digital math-based assets may be maintained,
tracked, and/or administered by the network.
[0185] A digital math-based asset system may use a decentralized
electronic ledger system, which may be maintained by a plurality of
physically remote computer systems. Such a ledger may be a public
transaction ledger, which may track asset ownership and/or
transactions in a digital math-based asset system. The ledger may
be a decentralized public transaction ledger, which can be
distributed to users in the network (e.g., via a peer-to-peer
sharing). Ledger updates may be broadcast to the users across the
network. Each user may maintain an electronic copy of all or part
of the ledger, as described herein. In embodiments, a digital asset
system may employ a ledger that tracks transactions (e.g.,
transfers of assets from one address to another) without
necessarily identifying the assets themselves.
[0186] In embodiments, a digital asset ledger, such as the Bitcoin
blockchain or the Ethereum blockchain, can be used to achieve
consensus and to solve double-spending problems where users attempt
to spend the same digital assets in more than one transaction. In
embodiments, before a transaction may be cleared, the transaction
participants may need to wait for some period of time, e.g., a six
confirmation wait (typically one hour in the context of the Bitcoin
network, 15 minutes in the context of the Litecoin network, to name
a few) before feeling confident that the transaction is valid
(e.g., not a double count). Each update to the decentralized
electronic ledger (e.g., each addition of a block to the Bitcoin
blockchain or the Ethereum blockchain) following execution of a
transaction may provide a transaction confirmation. After a
plurality of updates to the ledger (e.g., 6 updates) the
transaction may be confirmed with certainty or high certainty.
[0187] In embodiments, a blockchain can be a public transaction
ledger of the digital math-based asset that is maintained by a
distributed network, such as the Bitcoin network or the Ethereum
network. For example, one or more computer systems (e.g., miners)
or pools of computer systems (e.g., mining pools) can solve
algorithmic equations allowing them to add records of recent
transactions (e.g., blocks), to a chain of transactions. In
embodiments, miners or pools of miners may perform such services in
exchange for some consideration such as an upfront fee (e.g., a set
amount of digital math-based assets) and/or a payment of
transaction fees (e.g., a fixed amount or set percentage of the
transaction) from users whose transactions are recorded in the
block being added. In embodiments, digital assets in the form of a
digital asset token, such as Gas, may be used to pay such fees.
[0188] The digital asset network (e.g., Bitcoin network or Ethereum
Network) may timestamp transactions by including them in blocks
that form an ongoing chain called a blockchain. In embodiments, the
addition of a block may occur periodically, e.g., approximately
every 15 seconds, every minute, every 2.5 minutes or every 10
minutes, to name a few. Such blocks cannot be changed without
redoing the work that was required to create each block since the
modified block. The longest blockchain may serve not only as proof
of the sequence of events but also records that this sequence of
events was verified by a majority of the digital asset network's
computing power. The blockchain recognized by the nodes
corresponding to the majority of computing power, or some other
consensus mechanism, will become the accepted blockchain for the
network. In embodiments, confirmation of a transaction may be
attained with a high degree of accuracy following the addition of a
fixed number of blocks to the blockchain (e.g., six blocks) after a
transaction was performed and first recorded on the blockchain. As
long as a majority of computing power (or other consensus
mechanism) is controlled by nodes that are not cooperating to
attack the network, they will generate the longest blockchain of
records and outpace attackers.
[0189] There are a variety of consensus mechanisms (or protocols)
that may be used to verify transactions recorded in a blockchain. A
few non-limiting examples of these mechanisms are discussed below,
however, other protocols may be used in accordance with exemplary
embodiments of the present invention.
[0190] For example, the proof of control protocol is one example of
a consensus mechanism and is used, for example, in the Bitcoin
blockchain. A more detailed discussion of proof of control
protocols can be found in co-pending U.S. patent application Ser.
No. 15/920,042 filed Mar. 13, 2018 entitled SYSTEMS, METHODS, AND
PROGRAM PRODUCTS FOR VERIFYING DIGITAL ASSETS HELD IN A CUSTODIAL
DIGITAL ASSET WALLET, the entire content of which is hereby
incorporated by reference herein.
[0191] The proof of stake protocol is another optional protocol
that may be implemented by blockchains. In this type of protocol,
the validator's stake is represented by the amount of digital
assets held. Validators accept, reject or otherwise validate a
block to be added to the blockchain based on the amount of digital
assets held by the Validator on the blockchain. If the Validators
are successful in validating and adding the block, such a protocol,
in embodiments, will award successful Validators are a fee in
proportion to their stake.
[0192] The delegated proof of stake protocol is another protocol
that is available and is, for example, used by the EOS blockchain.
In this protocol, blocks are produced in a fixed number in rounds
(e.g., 21 for EOS). At the start of every such round, block
producers are chosen. A number less than all of the producers
(e.g., 20 in EOS) are automatically chosen while a corresponding
number are chosen proportional to the number of their votes
relative to other producers. In embodiments, the remaining
producers may be shuffled using a pseudorandom number derived from
the block time, for example. In embodiments, other forms of
randomized selection may be used. To ensure that regular block
production is maintained, in embodiments, block time is kept short
(e.g., 3 seconds for EOS) and producers may be punished for not
participating by being removed from consideration. In embodiments,
a producer has to produce a minimal number of block, e.g., at least
one block every 24 hours to be in consideration. All of the nodes
will, by default, not switch to a fork which does not include any
blocks not finalized by a sufficient majority (e.g., 15 of the 21
producers) regardless of chain length. Thus, in EOS, each block
must gain 15 of 21 votes for approval to be considered a part of
the chain.
[0193] In embodiments, a delegated byzantine fault tolerance
protocol may be used as a consensus mechanism. For example, NEO
uses this type of protocol. In this protocol, one of the
bookkeeping nodes is randomly chosen as a "speaker." The speaker
then looks at all the demands of the "citizens," (e.g., all of the
holders of the digital asset), and creates a "law" (e.g., a rule
governing the protocol). The speaker then calculates a "happiness
factor" of these laws to see if the number is enough to satisfy the
citizen's needs or not. The speaker then passes the happiness
factor down to the delegates (e.g., the other bookkeeping nodes).
The delegates may then individually check the speaker's
calculations. If the speaker's number matches the delegate's
number, then the delegates give their approval, and if not, then
they give their disapproval. In embodiments, a sufficient majority
(e.g., 66% in NEO) of the delegates need to give their approval for
the law to pass, i.e. for the block to be added. If a sufficient
majority is not obtained (e.g., less than 66% approval), then a new
speaker is chosen and the process starts again.
[0194] Ripple uses an algorithm in which each server gathers all
valid transactions that have not yet been applied and makes them
public. Each server then amalgamates these transactions and votes
on the veracity of each. Transactions that receive at least a
minimum number of yes votes will move into another round of voting.
A minimum of 80% approval is required before a transaction is
applied.
[0195] These and other protocols may be used to generate a
blockchain in accordance with exemplary embodiments of the present
invention.
[0196] In embodiments, transaction messages can be broadcast on a
best effort basis, and nodes can leave and rejoin the network at
will. Upon reconnection, a node can download and verify new blocks
from other nodes to complete its local copy of the blockchain.
[0197] In the exemplary Bitcoin system, a bitcoin is defined by a
chain of digitally signed transactions that began with its creation
as a block reward through bitcoin mining. Each owner transfers
bitcoin to the next owner by digitally signing them over to the
next owner in a bitcoin transaction which is published to and added
on to a block on the blockchain. A payee can then verify each
previous transaction, e.g., by analyzing the blockchain to verify
the chain of ownership.
[0198] Other examples of different types of blockchains noted above
that are consistent with embodiments of present invention pose
unique problems. Certain currencies present unique challenges in
that transactions and/or wallets or digital asset addresses
associated therewith may be shielded (e.g., not viewable by the
public on the ledger). For example, Monero is based on the
CryptoNight proof-of-work hash algorithm and possesses significant
algorithmic differences relating to blockchain obfuscation. Monero
provides a high level of privacy and is fungible such that every
unit of the currency can be substituted by another unit. Monero is
therefore different from public-ledger cryptocurrencies such as
Bitcoin, where addresses with coins previously associated with
undesired activity can be blacklisted and have their coins refused
by others.
[0199] In embodiments, "proof of brain" may be a type of token
reward algorithm used in social media blockchain systems that
encourages people to create and curate content. In embodiments,
proof of brain may enable token distribution by upvote and
like-based algorithms, which may be integrated with web sites to
align incentives between application owners and community members
to spur growth.
[0200] In particular, in Monero, ring signatures mix spender's
address with a group of others, making it more difficult to
establish a link between each subsequent transaction. In addition,
Monero provides "stealth addresses" generated for each transaction
which make it difficult, if not impossible, to discover the actual
destination address of a transaction by anyone else other than the
sender and the receiver. Further, the "ring confidential
transactions" protocol may hide the transferred amount as well.
Monero is designed to be resistant to application-specific
integrated circuit mining, which is commonly used to mine other
cryptocurrencies such as Bitcoin. However, it can be mined somewhat
efficiently on consumer grade hardware such as x86, x86-64, ARM and
GPUs, to name a few.
[0201] Another example of a modified blockchain consistent with
exemplary embodiments of the present invention discussed above is
Darkcoin. Darkcoin adds an extra layer of privacy by automatically
combining any transaction its users make with those of two other
users--a feature it calls Darksend--so that it will be more
difficult to analyze the blockchain to determine where a particular
user's money ended up.
[0202] Yet another example of a modified blockchain consistent with
exemplary embodiments of the present invention discussed above is
Zcash. The Zcash network supports different types of transactions
including: "transparent" transactions and "shielded" transactions.
Transparent transactions use a transparent address (e.g.,
"t-address"). In embodiments, transactions between two t-addresses
behave like Bitcoin transactions and the balance and amounts
transferred are publicly visible on the Zcash blockchain. Unlike
the Bitcoin Blockchain, the Zcash network may also support shielded
transactions using a shield address (e.g., "z-address"). In
embodiments, the "z-address" provides privacy via zero-knowledge
succinct noninteractive arguments of knowledge (e.g., "zk-SNARKS"
or "zero-knowledge proofs"). The balance of a z-address is not
publicly visible on the Zcash blockchain--the amount transferred
into and out of a z-address is private if between two
z-addresses--but may be public if between a z-address and a
t-address.
[0203] In embodiments, a digital asset based on a blockchain, may,
in turn, include special programming, often referred to as "smart
contracts", which allow for the creation of "tokens", which in turn
are digital assets based on digital assets. In embodiments, tokens
may be ERC-20 tokens, and used in conjunction with ERC-20 token
standard as a programming language. In embodiments, other protocols
may be used including but not limited to ERC-223 and ERC-721, to
name a few. In embodiments, smart contracts may be written on other
smart contracts to provide for increased functionality. One
non-limiting example of this type of structure is the open source
Cryptokitties game in which digital kittens are provided as ERC-721
tokens with a series of smart contracts provided to define how the
kittens will interact with each other and with users. In
embodiments, programming modules may be added to and/or transferred
with programming modules associated with specific tokens. By way of
illustration, a first token, e.g., a Cryptokitten Tiger, may
purchase a second token, e.g., a digital "hat," that will then
become associated with the first token to be a Tiger with a hat,
and remain with the first token when transferred. Thus, by way of
illustration, in the context of example embodiments of the present
invention, the first token could be, e.g., a security token, and
the second token could be, e.g., an account holding SVCoins, or a
right to request SVCoins from another account as discussed below.
If the first token is transferred, the second token would transfer
with the ownership of the first token.
[0204] For example, digital assets can include tokens, which like
other digital assets that can represent anything from loyalty
points to vouchers and IOUs to actual objects in the physical
world. Tokens can also be tools, such as in-game items, for
interacting with other smart contracts. A token is a smart contract
running on top of a blockchain network (such as the Ethereum
Blockchain, the Bitcoin Blockchain, to name a few). As such, it is
a set of code with an associated database. In embodiments, the
database may be maintained by an issuer. In embodiments, the
database may be included as part of the blockchain. In embodiments,
the ledger may be maintained in the first instance as a database in
a sidechain by the issuer or agent of the issuer and subsequently
published and stored as part of a blockchain. The code describes
the behavior of the token, and the database may be a table with
rows and columns tracking who owns how many tokens.
[0205] If a user or another smart contract within the blockchain
network (such as the Ethereum Network) sends a message to that
token's contract in the form of a "transaction," the code updates
its database.
[0206] So, for instance, as illustrated in FIG. 10, using a token
based on the Ethereum Network for illustration purposes, when a
wallet app sends a message to a token's contract address to
transfer funds from Alice to Bob, the following process occurs.
[0207] In embodiments, an underlying blockchain, like the Bitcoin
Block chain, may have limited or no smart contract
capabilities.
[0208] In such embodiments, an overlying protocol, such as Omni
Layer (https://www.omnilayer.org/) may also be used to create
custom digital assets on such an underlying blockchain, like the
Bitcoin blockchain, as described in
https://github.com/OmniLayer/spec. In embodiments, a smart contract
may be used for transactions involving Bitcoin through the use of a
two way peg with side chain. The side chain can share miners with
the Bitcoin blockchain and allows smart contracts to be run, such
as contracts using the Ethereum virtual machine. When Bitcoin is to
be used in the smart contract side chain, the Bitcoin is locked and
an equal amount of side chain currency, an example of which is
Super Bitcoin (SBTC), is assigned to the corresponding address.
After the smart contract transaction is completed, the side chain
currency is locked and the Bitcoin is unlocked. An example of such
a side chain is Rootstock.
[0209] In embodiments, where the blockchain is the Bitcoin
blockchain, and another protocol is used as a layer over the
Bitcoin blockchain to provide for smart contract functionality. For
example, the other protocol may be a two-way peg of stable value
digital asset tokens to bitcoin and a sidechain that shares miners
with the Bitcoin blockchain. In embodiments, the other protocol is
an omni layer protocol.
[0210] For illustration purposes, FIG. 10 shall be described with
respect to a token on a block chain with ERC20 smart chain
capabilities, such as the Ethereum Block chain and the NEO Block
chain, to name a few.
[0211] In step S1001, at the token issuer computer system, a token,
such as a Stable Value Token by way of illustration, is created. In
embodiments, the token can be other forms of tokens, such as a
Security Token, or other form of tokens. In embodiments, each token
may have a "ERC20 Contract Wallet Address" ("Contract Address")
which is an address on the blockchain at which the code for the
smart contract is stored. In embodiments, the smart contract may
include instructions to perform at least: (1) token creation, (2)
token transfer, (3) token destruction; and (4) updating smart
contract coding, to name a few. In addition, the smart contract may
include additional instructions related to authority to conduct
operations and/or transactions associated with the smart contract
or token.
[0212] In embodiments, of the present invention, the minimal
specification for a Token, such as a Stable Value Token, may
include instructions to perform at least: (1) a "total Supply"
function, which when called, will respond with a count of the
number of tokens in existence; (2) a "balanceOf" function, which
when called with a specific account (address) as a parameter,
responds with the count of the number of tokens owned by that
account; and (3) a "transfer" function, which is an example of a
state modifying function, that, when called, given one or more
target accounts and corresponding transferred amounts as
parameters, the transfer function will decrease the balance of the
caller account by the corresponding transfer amounts, and increase
the target accounts by the target amounts (or fail if the caller
account has insufficient amounts or if there are other errors in
the parameters).
[0213] In embodiments, a Stable Value Token may be created with a
fixed supply of tokens at the time of its creation. For example, a
Stable Value Token may be created with a supply of 21 million
tokens and set Address 1 (mathematically associated with a private
key 1) as the owner of all 21 million tokens. Thereafter, private
key 1 will be required to generate a call to the transfer function
in order to assign some portion of the 21 million tokens with a
second address 2 (mathematically associated with a private key 2)
or any other address (also mathematically associated with a
corresponding private key).
[0214] In embodiments, a Stable Value Token may be created with a
variable supply of tokens which can be set to increase or decrease
after original creation. In such embodiments, the minimum functions
required will also include: (4) a "print" function, which is
another example of a state modifying function, that when called
allows for the creation of additional Stable Value Tokens into the
total Supply of Stable Value Tokens; and (5) a "burn" function,
which is also another example of a state modifying function, that
when called allows for the destruction of previously created Stable
Value Token from the total Supply of the Stable Value Tokens. As
discussed below in greater detail, in embodiments, the print and
burn function may include limits on the Addresses that are allowed
to call those functions.
[0215] Currently, due to the immutable nature of the Ethereum
blockchain, once a smart contract is written to a specific Contract
Address it cannot be changed. However, in embodiments, the various
functions called for in the Contract Address may be associated with
specific authorized key pairs of public keys (or "addresses") and
corresponding private keys (which are mathematically associated
with public keys). In embodiments, one or more private keys may be
stored off-line in, what is sometimes referred to as, a designated
cold storage wallet associated with the token issuer. In such
embodiments, keys may be generated, stored, and managed on board
hardware security modules (HSMs). For example, HSMs, e.g., each a
"signer," should have achieved a rating of FIPS PUB 140-2 Level 3
(or higher) In embodiments, one or more private keys may be stored
on-line in, what is sometimes referred to as a designated hot
storage wallet associated with the token issuer. In embodiments,
the Contract Address may include instructions which are associated
with authorizing one or more designated key pairs stored off-line
in, e g., one or more cold storage wallets on one or more
air-gapped computer systems associated with the token issuer, but
may also give at least some permission to perform operations by one
or more designated key pairs stored on-line, in, e.g., one or more
hot wallets associated with the token issuer and/or a token
administrator on behalf of the token issuer on one or more computer
systems connected to the digital asset computer system. In
embodiments, the on-line computer systems would be co-located with
the digital asset computer systems. In embodiments, the Stable
Value Tokens may be created in batches (for example, 100,000
SVCoins worth $100,000 U.S. dollars) by a designated key pair (such
as an off-line designated key pair) authorized by smart contract
and assigned by such a key pair to a designated address associated
with on on-line public key for transactions as necessary.
[0216] In embodiments, a Stable Value Token database is maintained
in a blockchain, such as the Ethereum blockchain, for example. In
embodiments, the ledger may be maintained, in the first instance,
as a database in a sidechain by the issuer or agent and
subsequently published and stored as part of a blockchain.
[0217] In embodiments, a Stable Value Token database is maintained
in a blockchain, such as the Ethereum blockchain, for example. In
embodiments, the ledger may be maintained in the first instance as
a database in a sidechain by the issuer or agent and subsequently
published and stored as part of a blockchain.
[0218] In embodiments, Stable Value Tokens may be generated on the
fly, however, in this case, the contract code, which is the
executable code that is stored at the Contract Address location on
the blockchain, may designate one or more public addresses
corresponding to one or more on-line private keys held in, e.g., a
hot wallet(s), or one or more public addresses corresponding on one
or more off-line public keys held in, e.g., a cold wallet(s), or
some combination thereof, as the authorized caller of some
functionality. A more detailed discussion of exemplary structures
for hot wallets and cold wallets is presented in U.S. Pat. No.
9,892,460 issued Feb. 13, 2018 entitled SYSTEMS, METHODS, AND
PROGRAM PRODUCTS FOR OPERATING EXCHANGE TRADED PRODUCTS HOLDING
DIGITAL MATH-BASED ASSETS, the entire content of which is
incorporated by herein by reference. In embodiments, Contract
Wallets may be maintained by the token issuer and which would hold
the private key associated with the token on an associated device.
In embodiments, Contract Wallets may be provided on a user computer
device and hold the private key associated with the token. In such
embodiments, a user computer device may include a software
application to provide secure access to the token issuer such that
the user can engage in transactions.
[0219] In embodiments, a subset of two or more corresponding key
pairs from a larger collection of key pairs may be required to
engage in certain transaction. For example, 2 of 3, 2 of 5, or 3 of
5, keys may be required to engage in certain transactions. In
embodiments, such transactions may include sensitive or relatively
high risk transactions.
[0220] In embodiments, the smart contract(s) and associated
authorized private keys may be maintained by the SVCoin issuer and
which would hold the authorized private key(s) associated with the
token on an associated device.
[0221] By way of illustration, an ERC-20 Contract can include the
following representative type of functions as shown in Table 1 in
its programming of a Smart Contract associated with a particular
token, such as a security token or a stable value token:
TABLE-US-00001 TABLE 1 1 // 2 // ERC Token Standard #20 Interface 3
//
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standa-
rd.md 4 //
----------------------------------------------------------------------
------- 5 contract ERC20Interface { 6 function total Supply( )
public constant returns (uint); 7 function balanceOf(address
tokenOwner) public constant returns (uint balance); 8 function
allowance(address tokenOwner, address spender) public constant
returns (uint remaining); 9 function transfer(address to, uint
tokens) public returns (bool success); 10 function approve(address
spender, uint tokens) public returns (bool success); 11 function
transferFrom(address from, address to, uint tokens) public returns
(bool success); 12 13 event Transfer(address indexed from, address
indexed to, uint tokens); 14 event Approval(address indexed
tokenOwner, address indexed spender, uint tokens);
[0222] Some of the tokens may include further information
describing the token contract such as shown Table 2:
TABLE-US-00002 TABLE 2 1 string public constant name = ''Token
Name''; 2 string public constant symbol = ''SYM''; 3 uint8 public
constant decimals = 18; // 18 is the most common number of decimal
places
[0223] In embodiments, a more elaborate smart contract can be set
up to allow token issuers to have hybrid control over which key
pairs have authority to affect the token supply and distribution.
In embodiments, a hybrid combination of on-line and off-line key
pairs can be used to control the supply and distribution of
tokens.
[0224] For example, in embodiments, a smart contract may include a
state-changing function such as limitedPrint, where the authorized
caller of such function would be authorized only to print (or
issue) a specific limited amount of tokens. In embodiments, the
limitedPrint function may authorize printing or issuing of tokens
for a set period of time. In embodiments, the limitedPrint function
may authorize printing or issuing of only a certain number of
tokens over a set period of time. In embodiments, the limitedPrint
function may be used with an on-line key pair (e.g., hot wallet),
to allow for fast and efficient token creation, but limit risk of
unauthorized takeover of the on-line key pair to the set limit.
[0225] In conjunction with a limitedPrint command, a separate
state-changing function of raiseCeiling can be used to increase the
authority for the on-line key pair using a different key pair, such
as an off-line key pair (e.g., cold wallet), which is considered to
be more secure.
[0226] In embodiments, using a limitedPrint function with a set
limit that can be implemented by one or more designated on-line key
pairs (e.g., hot wallets), and a raiseCeiling function which may
change that limit under the authority of a different set of one or
more designated off-line key pairs (e.g., cold wallets), the
automated increases in the token supply through on-line control
will only continue up until the ceiling is reached, at which point
further intervention through off-line control is required. In
embodiments, a subset of two or more corresponding key pairs from a
larger collection of key pairs may be required to engage in certain
transaction. For example, 2 of 3, 2 of 5, or 3 of 5, to name a few,
keys may be required to engage in certain transactions. In
embodiments, as noted above, such transactions may include
sensitive or relatively high-risk transactions.
[0227] One should consider the difference between the current token
supply and the supply ceiling as part of the tokens at risk. If the
current token supply has decreased through the use of burn, then
the effective funds at risk could have increased without a
corresponding decrease in the supply ceiling. The ceiling can be
lowered by on-line control, through a function called lowerCeiling.
This allows for relinquishing some portion of what has been granted
through off-line control to limit the effective funds at risk
through compromise of on-line key management systems. In
embodiments, a limit on number of tokens that can be burned may
also be included.
[0228] In embodiments, as illustrated in FIG. 13A, the token may be
set up using at least three core smart contracts, e.g., ERC20Proxy
1310, ERC20Impl 1320, and ERC20Store 1330 that cooperatively
implement an ERC20 compliant token.
[0229] In the context of a ERC20 compliant token on the Ethereum
blockchain, there is one, and will only ever be one instance of
ERC20Proxy 1310. This is the smart contract that users of the token
treat as the token contract. Thus, ERC20Proxy 1310 can be
considered the permanent face of interacting with the token on the
Ethereum blockchain.
[0230] However, in embodiments, ERC20Proxy 1310 may have almost no
code and does not keep any state information itself. Instead, in
embodiments, ERC20Proxy 1310 has one or more implementations (e.g.,
ERC20 Impl 1320, ERC20 Impl (1) 1340, ERC20 Impl (2), to name a
few) that executes the logic of the token. S1312 "impl" represents
a delegation from ERC20 Proxy 1310 to ERC20Impl 1320. Thus, the
instance of ERC20Impl 1320 executes the specific delegated
functions. ERC20Impl 1320 may further limit the authority to
implement to the specific delegated functions to only specified
trusted callers (e.g., as shown in FIGS. 13C, 13G and 13H, one or
more off-line key set 1362, one or more on-line key set 1364, to
name a few). S1314 proxy illustrates the authorization of ERC20Impl
1320 executing logic on behalf of ERC20Proxy 1310, through call
functions from one or more authorized addresses.
[0231] In embodiments, state information, such as token balances,
may be maintained in a separate instance, e.g., ERC20Store 1330, a
"backing store." In such embodiments, ERC20Store 1330 would own the
delegated state of the token. S1322 "store" illustrates the
delegation of state information from ERC20Impl 1320 to ERC20Store
1330. In embodiments, the instance of ERC20Store 1330 may execute
updates to the state of the token, such as updates to token
balances that occur during a token transfer to one or more
designated key sets. S1324 "impl" represents the address that the
ERC20Store 1330 will permit to invoke the update functions. In
embodiments, that address is the "Contract Address" of the active
version of ERC20Impl 1320.
[0232] This separation of duties--public face, logic, and storage,
for ERC20Proxy 1310, ERC20Impl 1320, and ERC20Store 1330,
respectively--provides the ability for token issuer to replace the
logic of the system at a later date. In embodiments, the logic may
be replaced by changing the impl arrows (e.g., S1312 "impl" and
S1324 "impl").
[0233] FIG. 13B illustrates an embodiment where a token has been
upgraded, by creating a new instance of ERC20Impl (ERC20Impl (2)
1320A) with a second version of the code previously implemented
through ERC20Impl 1320. The instance of ERC20Proxy 1310 now
delegates its implementation in S1312A "impl" to ERC20Impl (2)
1320A (version 2 of the code) instead of the previous ERC20Impl
1320 (version 1), and the instance of ERC20Store 1330 will now only
accept calls from ERC20Impl 1320A (version 2). The original
ERC20Impl 1320 (version 1) remains, but has become inert as it is
unlinked from the system.
[0234] Turning to FIGS. 13C-13F, custodianship will be
discussed.
[0235] In embodiments, a fourth type of contract, Custodian 1350,
may also be implemented. A Custodian 1350 is logic which designates
which key pair (e.g., an Off-Line Keyset 1362), is authorized to
control other contracts in the system (e.g., ERC20Proxy 1310).
Contracts cooperate with Custodian 1350 by awaiting an approval
from Custodian 1350 before executing certain actions. In turn, such
approval will require a message from an authorized key pair (e.g.,
Off-Line Keyset 1362) authorizing the action (e.g., print tokens,
limit tokens, transfer tokens, to name a few).
[0236] In embodiments, Custodian 1350 may include a range of
control coding. In embodiments, control coding may include the
requirement that at least two designated keysets authorize a
specific action (e.g., print token). In embodiments, at the least
two keysets may be a subset of a larger group of keysets (e.g., two
of three designated keysets, or two of six designated keysets, or
three of five designated keysets, to name a few). In embodiments,
when a higher degree of security is desired, the keysets may be
maintained off-line. In embodiments, when a higher degree of
automation or speed to access is required, the keysets may be
maintained on-line, such as in a co-located, but separate computer
system that is operatively connected to a customer facing digital
asset system.
[0237] In embodiments, Custodian 1350 may also exercise control
over various security operations of ERC20Proxy 1310 (e.g., time
locking and revocation, to name a few).
[0238] In embodiments, Custodian 1350 may have custodianship of the
proxy which grants exclusive power to replace the implementation
for ERC20Proxy 1310 from its current implementation (e.g.,
ERC20Impl 1320 (version 1)) to a new implementation (e.g.,
ERC20Impl 1320A (version 2)), as illustrated in FIG. 13B, discussed
above. As discussed, in embodiments, only authorized and designated
key sets (e.g., off-line key set 1362) will have the authority in
step S1354 signers to authorize the Custodian 1350 to modify an
implementation of ERC20Proxy 1310.
[0239] In embodiments, Custodian contracts with their own
respective authorized designated keysets can be set up for other
contracts, such as ERC20Store 1330 as also shown in FIG. 13C. Thus,
by way of example, ERC20Store 1330 may designate in S1332 Custodian
1350A as a custodian for certain operations of ERC20Store. Those
operations will only be executed by ERC20Store 1330 when designated
keyset (such as Off-Line keyset 1362A) sends a message through the
blockchain to Custodian 1350A authorizing the Custodian 1350A to
authorize the ERC20Store 1330 to perform the designated function.
In embodiments, the off-line keyset 1362A may be the same as,
overlap with, or be different from the Off-Line Key Set 1362A which
may authorize Custodian 1350 with respect to ERC20Proxy 1310.
[0240] In embodiments, custodianship of the proxy and store also
grants exclusive power to pass custodianship to a new instance of
Custodian. Thus, one of the technical computer problems associated
with the immutability of ERC20 smart contracts on the Ethereum
blockchain has been solved, thus allowing for a self-upgrade of
custodianship. In embodiments, since a set of signers for a given
instance of a Custodian is fixed, a change to the off-line keyset
may be implemented instead having a current Custodian authorize
itself to be replaced by a new instance of Custodian with a new set
of signers.
[0241] Referring now to FIGS. 13D-13F, an exemplary process of
upgrading active implementation of the pointer relationship of
ERCProxy 1310 from ERC20Impl 1320 (version 1) to ERC20Impl 1320A
(version 2) will now be discussed.
[0242] FIG. 13D reflects the initial state in which ERC20Proxy 1310
has Custodian 1350 and in S1312A implemented ERC20 Impl 1320
(version 1) to act as a proxy in S1314A for certain functions of
ERC20Proxy 1310.
[0243] To swap out the current ERC20Imp11320 (version 1) with an
updated ERC20Impl 1320 (version 2), as shown in FIG. 13E, the
coding for ERC20 Impl 1320 (version 2) needs to be deployed on the
blockchain and set its proxy point (S1314B proxy) to the same
ERC20Proxy 1310.
[0244] Next, the implementation pointer from ERC20Proxy 1310 which
is currently set at S1312 (impl) to point to ERC20Impl 1320
(Version 1), needs to be reset to be S1312B "impl" to point to
ERC20Impl 1320A (version 2) instead. This change requires the
authorization of Custodian 1350, which in turn requires two
signatures from keys in its designated keyset (e.g., Off-Line
Keyset 1362) sent to it on the blockchain.
[0245] Table 3 represents an exemplary embodiment of the steps used
to implement this process:
TABLE-US-00003 TABLE 3 1. lockID = proxy.requestImplChange(imp_2)
2. request=
custodian.requestUnlock(lockId,proxy.confirmImpl.Change) 3.
Off-line signing of request 4. custodian.completeUnlock (request,
signature_1, signature 2) a. proxy.confirmImplChange(lockID)
[0246] Referring to Table 3, in step 1, a request must be made to
ERC20Proxy to change its instance of ERC20Impl. This request may
come from any address, and when the request is made, the function
returns a unique lockId that anyone can use to look up that
request.
[0247] Next, in step 2, to confirm the pending request, the
Custodian contract 1350 for ERC20 Proxy 1310 calls requestUnlock
and passes as arguments the lockId generated for the change
request, and the function in ERC20Proxy 1310 the Custodian 1350
needs to call to confirm the change request. This generates a
request, which is a unique identifier for this unlock request.
[0248] In step 3, to complete the unlocking of Custodian and
therefore propagate the change to ERC20Proxy 1310, the digital
asset system operated by the token issuer uses its off-line key
storage infrastructure to sign the request with the previously
approved designated key sets. In this example, two signatures are
required (signature 1 and signature 2), but other combinations of
signatures may be used consistent with embodiments of the present
invention.
[0249] In step 4, those signatures are passed into the Custodian's
completeUnlock function along with the initial request. Once the
request is validated against the signatures, completeUnlock parses
the content of the request and issues the command. In this case, it
calls ERC20Proxy's confirmImplChange using the lockId generated in
the initial ERC20Impl change request.
[0250] As shown in FIG. 13F, ERC20Proxy 1310 now points with S1312B
to the updated ERC20Impl 1320A (version 2) contract, thus
delegating all future calls from ERC20Proxy 1310 to the updated
contract ERC20 Impl (version 2) 1320A. This process can be repeated
in the future to upgrade the ERC20 Impl (version 2) 1320A to new
versions as authorized by the Custodian 1350.
[0251] In embodiments, a similar process may also be used to
upgrade the active Custodian 1350. Instead of the pair of functions
requestImplChange and confirmImplChange, the pair of functions
requestCustodianChange and confirmCustodianChange are used
instead.
[0252] Referring to FIGS. 13G and 13H, a PrinterLimiter 1360
contract may also be used as an upgradeable limit on the token
supply available.
[0253] In the context of FIG. 13G, ERC20Impl 1320 allows printing
an unbounded amount of tokens to any arbitrary address. This
printing can only be done by PrintLimiter 1360 contract, which
serves as ERC20Impl's custodian. However, PrintLimiter 1360 can
only call this unbounded printing if it receives a call from its
custodian, a separate contract named Custodian 1350, which is in
turned controlled by signatures from designated keysets (e.g.,
Off-Line Key Set 1362).
[0254] Thus, to print an unbounded amount of tokens, signatures
from keys in Off-Line Key Set 1362 need to be sent through the
blockchain, to Custodian 1350, which, in turn, then calls through
the blockchain, PrintLimiter 1360, which then, in turn, calls
through the blockchain ERC20Impl 1320 to confirm the print
request.
[0255] Referring to FIG. 13H, a limited printing option may also be
implemented. Thus, In embodiments, consistent with FIG. 13H,
ERC20Impl 1320 allows either printing an unbounded amount (which
originates from Off-Line Key Set 1362 as described earlier), or a
limited amount which does not require the Off-Line Key Set 1362 to
enact. Within PrintLimiter 1360 is a "total supply ceiling"
variable: a maximum total supply of tokens that any "limited print"
operation cannot exceed. This value is set by Off-Line Key Set
1362. PrintLimiter 1360 allows printing new tokens while remaining
under that ceiling from a special hot wallet address. That hot
wallet address can call PrintLimiter 1360 directly, which then
calls ERC20Impl 1320 to confirm the "limited" print operation. In
embodiments, limits may also be expressed in units of tokens to be
issued, time periods or units of tokens per unit of time. In
embodiments, for higher risk activities, a time delay may be
implemented even where the activity is authorized. For example,
where a large number of tokens are to be printed, a time delay of,
e.g. 15 minutes, may be implemented even after authorization is
confirmed.
[0256] The total supply ceiling can only be raised by Off-Line Key
Set 1362. In embodiments, it can be lowered, however, by On-Line
Key Set 1364 or Off-Line Key Set 1362.
[0257] Table 4 illustrates exemplary embodiments of code used in
smart contracts on the Ethereum blockchain which implement a
cooperative relationship with an external account or contract that
exerts custodianship over the contract following the pattern.
[0258] A contract following this type of pattern is capable of
carrying out some action--a portion of the desired operations;
however, rather than executing the action directly, the action is
first requested, with a unique `lock identifier` returned as the
result of the request. The pending action is stored in the contract
state, storing the data necessary to execute the action in the
future, and with the lock identifier as the lookup key to retrieve
the pending action. If the contract is called by its custodian,
receiving a lock identifier as an argument, then the associated
pending action, if any, is retrieved and executed.
[0259] In embodiments, as illustrated in Table 4, the contracts may
include multiple inheritances, so for the purposes of code reuse, a
function for generating unique lock identifiers is implemented in
the contract LockRequestable.
TABLE-US-00004 TABLE 4 contract LockRequestable { uint256 public
lockRequestCount; function LockRequestable( ) public {
lockRequestCount = 0; } function generateLockId( ) internal returns
(bytes32 lockId) { return keccak256(block.blockhash(block.number -
1), address(this), ++lockRequestCount); } }
[0260] In embodiments, the function generateLockId returns a
32-byte value to be used as a lock identifier, which is a hash of
the following three components: (1) The blockhash of the Ethereum
block prior to the block that included the Ethereum transaction
that executed this function; (2) The deployed address of the
instance of the contract that inherits from LockRequestable; and
(3) The current value of the count of all invocations of
generateLockId (within `this` contract).
[0261] Component three plays the role of a nonce (in cryptography,
a nonce is an arbitrary number that can be used just once) ensuring
that a unique lock identifier is generating no matter how many
invocations of generateLockId there are within a single Ethereum
transaction or a single Ethereum block.
[0262] Component two ensures that the lock identifier is unique
among the set of cooperating contracts that use this identifier
generation scheme. A noncooperative contract authored by a third
party may choose to generate identifiers that overlap, but that is
expected not to impact operation.
[0263] Finally, component one uses the relative previous blockhash
to make future lock identifiers unpredictable.
[0264] Table 5 illustrates embodiments of code which uses
LockRequestable in a template consistent with embodiments of the
present invention.
TABLE-US-00005 TABLE 5 contract C is ..., LockRequestable { struct
PendingAction { t v; ... address public custodian; mapping (bytes32
=> PendingAction) public pendingActionMap; function C(address
_custodian, ...) public { custodian = _custodian; ... } modifier
onlyCustodian { require(msg.sender == custodian); _; } function
requestAction(t_v, ...) public returns (bytes32 lockId) {
require(_v != 0); lockId = generateLockId( );
pendingActionMap[lockId] = PendingAction({ v: _v, ... }); emit
ActionLocked(lockId, _v, ...); } function confirmAction(bytes32
_lockId) public onlyCustodian { PendingAction storage pendingAction
= pendingActionMap[_lockId]; t v = pendingAction.v; require(v !=
0); ... // copy any other data from pendingAction delete
pendingActionMap[_lockId]; ... // execute the action emit
ActionConfirmed(_lockId, v, ...); } event ActionLocked(bytes32
lockId, t _v, ...); event ActionConfirmed(bytes32 lockId, t _v,
...); }
[0265] The function requestAction generates a fresh lock identifier
and captures the request parameters as a pending action, storing it
in a mapping associated with the lock identifier.
[0266] The function confirmAction is callable only by the
designated custodian. The given lock identifier is used to retrieve
the associated pending action from the contract storage, if it
exists, otherwise the function reverts. The pending action is
deleted from storage, which ensures that the action will be
executed at most once. Finally, the logic of the action is
executed.
[0267] In embodiments, there are two requirements to the
confirmAction callback function: (1) The function does not have a
return value; and (2) The function must only revert if there is no
pending action associated with the lock identifier.
[0268] In these embodiments, the custodian receives a failure
signal only when it called with an invalid lock identifier. Any
failure cases that may occur in the execution of the action logic
must be signaled by means other than return values or reversions
(including abortive statements such as throw).
[0269] Programming consistent with Tables 4 and 5 may be used to
implement a wide variety of functions in the context of a token
including, by way of example: [0270] Contracts that inherit from
the ERC20ImplUpgradeable contract (e.g., ERC20Proxy and ERC20Store)
control updates to the address that references an instance of the
ERC20Impl contract; [0271] The ERC20Impl contract to control
increases to the token supply; [0272] The ERC20Holder contract to
control `withdrawal` transfers out of its balance; [0273] The
PrintLimiter contract to control increases to its token supply
ceiling state; and [0274] Contracts that inherit from the
CustodianUpgradeable contract (e.g., ERC20Proxy, ERC20Impl, and
ERC20Store) to control the passing of custodianship itself from the
current custodian to a new custodian, to name a few.
[0275] In embodiments, other limits or controls may also be built
into the smart contract functionality of the token. For example, in
embodiments, it may be necessary for the token issuer to adjust the
token ledger to account for regulatory activity. For example, there
may be a court ordered seizure of funds, or a security issue that
may require reversing transactions during a compromised period, to
name a few.
[0276] In embodiments, as discussed below, an exchange system may
include fraud management computer system 5160. In embodiments, the
administrator system and/or stable value token issuer system may
include, or be operably connected to, fraud management computer
system 5160 or a comparable fraud management computer system. In
embodiments, the fraud management computer system may be operated
by the exchange, the administrator, the stable value token issuer
or a third party, to name a few.
[0277] In embodiments, the fraud management computer system may
monitor the blockchain to identify public addresses to and/or from
which Stable Value Tokens may be transferred. In embodiments, the
fraud management computer system may compare the identified public
addresses to one or more lists of suspicious public addresses. In
embodiments, where one of the identified public addresses
corresponds to a suspicious public address, a report may be issued
to reflect possible suspicious activity. In embodiments, the report
may be provided to the exchange, administrator or stable value
token issuer and/or regulatory or law enforcement authorities. In
embodiments, the exchange system, administrator system and/or
stable value token issuer system may block a transaction to and/or
from a suspicious public address. In embodiments, the exchange
system, administrator system and/or stable value token issuer
system may freeze any Stable Value Tokens associated with the
suspicious public address. In embodiments, the exchange system,
administrator system and/or stable value token issuer system may
reverse a transfer of Stable Value Tokens to and/or from the
suspicious address.
[0278] In embodiments, the fraud management computer system may be
operably connected to ledger information and/or other relevant data
to monitor the creation, destruction and/or transfer of the Stable
Value Tokens to identify suspicious and/or potentially fraudulent
and/or criminal activity. In embodiments, the fraud management
computer system will monitor activity and compare it to a
suspicious activity database. In embodiments, in the event that
suspicious, possibly fraudulent and/or possibly criminal activity
is identified, the fraud management computer system may generate a
report identifying such activity. In embodiments, the report may be
provided to the exchange, the administrator and/or the stable value
token issuer and/or may be sent to regulatory or law enforcement
authorities. In embodiments, depending on the nature of the
activity identified in the report, action may be taken which may
include, but is not limited to, freezing an account, blocking a
transaction involving the Stable Value Token on the blockchain
and/or modifying account information, to name a few.
[0279] In embodiments, the fraud management computer system may:
(1) identify and assess the full range of fraud-related and similar
risk areas, including market manipulation; (2) provide procedures
and/or controls to protect against identified risks; (3) allocate
responsibility for monitoring risks; and/or (4) periodically or
aperiodically evaluate and/or revise these procedures, controls
and/or monitoring processes, to name a few.
[0280] In embodiments, as noted above, upon discovery of any
wrongdoing or suspected wrongdoing, the fraud management computer
system may generate reports to the appropriate regulatory agency or
agencies, including but not limited to: (1) a report stating all
pertinent details known; (2) a supplemental report of any material
developments relating to the originally reported events; (3) a
statement of the actions taken (or proposed to be taken) with
respect to such developments; and (4) a statement of changes, if
any, in the entities' operations that have been put in place, or
are planned, in order to avoid repetition of similar events, to
name a few.
[0281] In embodiments, the fraud management computer system may
freeze, temporarily and permanently, the use of and/or access to
Stable Value Tokens (SVCoins) and/or fiat currency held or
controlled by the exchange, administrator and/or stable value token
issuer. In embodiments, a Stable Value Token and/or fiat currency
available on redemption of the Stable Value Token may be forfeited
if the Stable Value Token is being used for or has been used for
illegal activity. In embodiments, in the event that a legal order
or other legal process requires the exchange, administrator and/or
stable value token issuer to do so, any Stable Value Token and/or
the fiat currency available upon exchange of the Stable Value Token
may be subject to forfeiture to, or seizure by, a law enforcement
agency. In embodiments, any Stable Value Token and/or fiat currency
available upon exchange of Stable Value Token that has been subject
to freezing, forfeiture to or seizure by a law enforcement agency,
and/or subject to any similar limitation on its use, may be wholly
and permanently unrecoverable and unusable and may, in appropriate
circumstances, be destroyed.
[0282] In embodiments, the administrator may send instructions to
modify the token supply for one or more particular accounts. For
example, the smart contract may include instructions to pause a
transfer. The pause function may be a permanent pause, e.g., for a
compromised account, a time limited pause, e.g., for 24 hours or 2
days, or a temporary pause which requires another instruction to
reactivate the account, to name a few. Such a function could be
included as an upgrade feature in a new Impl contract, or built
into the smart contract to be activated when an authorized account,
e.g., one or more off-line keys call upon the smart contract to
implement the pause functionality, with appropriate parameters.
[0283] In embodiments, the administrator may send instructions to
rebalance the token supply of one or more particular accounts. For
example, the smart contract may include instructions to adjust a
token balance in a designated account, e.g., by raising the balance
in the designated account, lowering the balance in the designated
account, or transferring some or all of the tokens in one
designated account to one or more other designated accounts. Such a
function could be included as an upgrade feature in a new Impl
contract, or built into the smart contract to be activated when an
authorized account, e.g., one or more off-line keys, call upon the
smart contract to implement the pause functionality, with
appropriate parameters.
[0284] In embodiments, the Stable Value Token may be embodied in
the form of a token on the Ethereum Blockchain, referred to as a
Gemini Dollar token, as illustrated in the exemplary dashboard of
FIGS. 15A-15C.
[0285] FIG. 15A illustrates an exemplary GUI for an interface with
the digital asset exchange in which a user can deposit/redeem
Gemini Dollar tokens into an public address associated with the
digital asset exchange, in exchange for an corresponding amount of
fiat in the user's account at the digital asset exchange. In
embodiments, after the registered user of the exchange deposits the
stable value token into the exchange's public address, the exchange
will transfer from the bank account or other account associated
with the stable value token, a corresponding amount of fiat, to the
bank account associated with the fiat holdings of the user. In
embodiments, the deposited token will then be burnt from
circulation. In embodiments, the deposited token may instead of
being burnt be redistributed to another customer, but in such case,
an appropriate amount of fiat will need to be redeposited into the
bank account or other stable investment vehicle associated with the
stable value token.
[0286] In embodiments, creation and redemption of the Gemini Dollar
tokens may be made simple to promote usability and encourage
adoption. In embodiments, Gemini Dollar tokens are redeemed or
"destroyed" at the time of deposit into a digital asset exchange.
Exchange customers may exchange Gemini Dollar tokens for U.S.
dollars at a 1:1 exchange rate by depositing Gemini Dollar tokens
into their exchange account. The U.S. dollar amount of Gemini
Dollar tokens will be credited to the customer's exchange account
balance at the time of deposit.
[0287] The process described in FIGS. 17A-17E illustrates an
embodiment of depositing/redeeming stable value digital asset
tokens (i.e. Gemini Dollar tokens) in exchange for fiat.
[0288] In step S1702 of FIG. 17A, a digital asset exchange computer
system associated with a digital asset exchange receives and
authenticates an access request from a first user device associated
with a first user. FIG. 17B provides a detailed illustration of an
exemplary process for authenticating the first user that may be
used in accordance with exemplary embodiments of step 1702. In
embodiments, In step S1702A, the digital asset exchange computer
system receives an authentication request from the first user
device. In embodiments, the authentication request includes first
user credential information associated with the first user.
[0289] At step S1702B, the digital asset exchange computer system
determines that the first user device is authorized to access the
digital asset exchange computer system based at least on the first
user credential information. In embodiments, the digital asset
exchange computer system may further determine that the first user
is a registered user of the digital asset exchange. In embodiments,
the digital asset exchange may be licensed by a government
regulatory authority.
[0290] At step S1702C, the digital asset exchange computer system
generates first graphical user interface (GUI) information for
displaying a first graphical user interface on the first user
device. FIG. 15A illustrates an example of such a first graphical
user interface. In step S1702D, the digital asset exchange computer
system transmits the first graphical user interface information to
the first user device.
[0291] Referring back to FIG. 17A, in step S1704, the digital asset
computer system obtains a deposit request from the first user
device. FIG. 17C provides a detailed illustration of an exemplary
embodiment of obtaining a deposit request that may be used in
accordance with exemplary embodiments of step 1704. At step S1704A,
the digital asset exchange computer system receives a first
electronic request from the first user device. The first electronic
request may be to deposit stable value digital asset tokens. In
embodiments, each stable value digital asset token is tied to an
underlying digital asset which is maintained on a distributed
public transaction ledger in the form of a blockchain maintained by
a plurality of geographically distributed computer systems in a
peer-to-peer network in the form of the blockchain network. In
embodiments, the underlying digital asset is ether, and the
blockchain is the Ethereum Blockchain. In embodiments, the
underlying digital asset is neo and the blockchain is the Neo
Blockchain. In embodiments, the underlying digital asset may be
based on other blockchains that provide smart contract
functionality.
[0292] In step S1704B, in response to receiving the first
electronic deposit request, the digital asset exchange computer
system obtains first account balance information of the first user
indicating a first amount of available fiat for the first user held
by the digital asset exchange on behalf of the first user. In
embodiments, the digital asset exchange computer system obtains the
first amount of available fiat from a fiat account ledger database
stored on a computer readable member accessible by the digital
asset exchange computer system.
[0293] In step S1704C, the digital asset exchange computer system
obtains a user specific destination address. The user specific
destination address may be uniquely associated with the first user.
In step S1704D, the digital asset exchange computer system
generates second graphical user interface information including at
least the first account balance information and the user specific
destination address. In embodiments, the graphical user interface
described in step S1704C may be the graphical user interface shown
in connection with FIG. 15A.
[0294] At step 1704E, the digital asset exchange computer system
may transmit the second graphical user interface information to the
first user device. In embodiments, this may cause the first user
device to display the graphical user interface shown in connection
with FIG. 15A.
[0295] In step 1704F, the digital asset exchange computer system
may receive a second electronic deposit request form the first user
device. In embodiments, the second electronic deposit request may
comprise at least: (1) a first amount of stable value digital asset
tokens to be deposited; (2) a designated public address of the
first user on the underlying blockchain from which the first amount
of stable value digital asset tokens will be transferred; and (3) a
digital signature based on a designated private key of the first
user. In embodiments, the designated private key of the first user
is mathematically related to the designated public address of the
first user.
[0296] In embodiments, the designated private key of the first user
may be stored in a custodial system, the custodial system may be
part of digital asset exchange computer system, the administrator
system, the stable value token issuer system or a third party
system and may be accessed to provide the digital signature based
on authorization of the first user. In embodiments, the first user
may authorize transactions based on authentication information. In
embodiments, the authentication information may include a user name
and password associated with the first user. In embodiments,
multi-fact verification may be necessary in order for the first
user to authorize the custodial system to access the designated
private key and provide a digital signature to authorize a
transaction. In embodiments, the multi-fact verification may
include the use of an authorization code that is sent to a
predetermined user device, e-mail address, or mobile phone number,
to name a few, associated with the first user, for example, as used
in AUTHY.RTM. (AUTHY.RTM. is a registered trademark of Twilio,
Inc.). In embodiments, other multi-factor verifications may be
used, such as identification of a user device associated with the
first user based on phone number or mobile network, location
information and shared secret verification, to name a few.
[0297] Referring back to FIG. 17A, in step S1706, the digital asset
exchange computer system processes the second electronic deposit
request. FIGS. 17D-17E provide a detailed illustration of an
exemplary embodiment of processing the second electronic deposit
request that may be used in accordance with exemplary embodiments
of step 1706. Referring to FIG. 17D, in step S1706A, the digital
asset exchange computer system calculates a second amount of fiat
based on the first amount of stable value digital asset tokens. In
embodiments, the second amount of fiat is determined using a fixed
predetermined ratio of stable value digital asset tokens to fiat.
In embodiments, the fiat is U.S. Dollars. In the embodiments where
the fiat is U.S. Dollars, the fixed predetermined ratio may be one
stable value digital asset token is equal to one U.S. Dollar. In
embodiments, the fixed predetermined ratio may be one hundred
stable value digital asset tokes is equal to one U.S. Dollar.
[0298] In step S1706B, the digital asset exchange computer system
determines that the first amount of stable value digital asset
tokens is present at the designated public address of the first
user. In the case where the first amount of stable value digital
asset tokens is present at the designated public address of the
first user, as indicated in step S1706C, the digital asset exchange
computer system determines a third amount of fiat associated with
an updated amount of available fiat of the first user. In
embodiments, the third amount of fiat equals the first amount of
available fiat of the first user plus the second amount of
fiat.
[0299] At step 1706D, the digital asset computer system updates the
fiat account ledger to reflect that the updated amount of available
fiat of the first user is the third amount of fiat. At a step
1706E, the digital asset exchange computer system generates a first
transaction request for the blockchain from a first digital asset
exchange public key address on the blockchain to a first contract
address associated with a stable value token issuer. In
embodiments, the first digital asset exchange public key address is
mathematically related to a first digital asset exchange private
key which is stored in the computer readable member accessible by
the digital asset exchange computer system.
[0300] In embodiments, the first transaction request includes: (1)
a request to obtain the first amount of stable value digital asset
tokens from the designated public address of the first user; and
(2) a request to destroy the first amount of stable value digital
asset tokens. In alternative embodiments, the first transaction
request may include: (1) a request to obtain the first amount of
stable value digital asset tokens from the designated public
address of the first user; and (2) a request to provide the first
amount of stable value digital asset tokens to a specific
destination address. In embodiments, the first transaction request
is signed with a generated digital signature based on the digital
asset exchange private key of the digital asset exchange.
[0301] In step 1706F, the digital asset exchange computer system
may update a stable value digital asset token issuer fiat ledger.
The update may decrease the balance of fiat by the second amount of
fiat. In embodiments, the digital asset exchange computer system
may transfer the second amount of fiat from a stable value digital
asset token issuer to a digital asset exchange fiat account. In
embodiments, the digital asset exchange computer system may
periodically transfer fiat between a stable value digital asset
token issuer fiat account and a digital asset exchange fiat account
based on net transactions over a predetermined period of time.
[0302] At step S1706G, the digital asset exchange computer system
may transmit the first transaction request to the blockchain
network via the Internet. In step, S1706H, the digital asset
exchange system confirms, via reference to the blockchain, that the
first amount of stable value digital asset tokens are not present
at the designated public address of the first user.
[0303] FIG. 15B illustrates an exemplary GUI for an interface with
the digital asset exchange in which a user can withdraw/purchase
stable value tokens in the form of Gemini Dollar tokens from their
digital asset exchange account. In this exemplary embodiment, the
amount of the withdrawal is expressed in U.S. Dollars, and a
corresponding amount of U.S. Dollars is debited from the user's
fiat account with the exchange. As part of the withdrawal process,
the digital asset exchange may arrange to issue new stable value
tokens to the customer at the specified digital asset exchange in
accordance with embodiments elsewhere described. In embodiments,
the digital asset exchange may instead transfer pre-existing stable
value tokens instead. As noted above, since the stable value token
is pegged to a predetermine ratio of fiat, (e.g., 1 Gemini
Dollar=USD 1, or 100 Gemini Dollar=USD 1), expressing the
withdrawal amount in dollars is sufficient to allow the user and
the digital asset system to determine the amount of Gemini Dollars
tokens being withdrawn/purchased.
[0304] FIGS. 16A-16E illustrate an embodiment of
withdrawing/purchasing stable value digital asset tokens (i.e.
Gemini Dollar tokens) in exchange for fiat.
[0305] In step S1602 of FIG. 16A, a digital asset exchange computer
system associated with a digital asset exchange receives and
authenticates an access request from a first user device associated
with a first user. FIG. 16B provides a more detailed illustration
of an exemplary embodiment of receiving and authenticating an
access request from a first user device associated with a first
user that may be used in accordance with exemplary embodiments of
step 1602. At step S1602A, the digital asset exchange computer
system receives an authentication request from the first user
device. In embodiments, the authentication request includes first
user credential information associated with the first user.
[0306] At step S1602B, the digital asset exchange computer system
determines that the first user device is authorized to access the
digital asset exchange computer system based at least on the first
user credential information. In embodiments, the digital asset
exchange computer system may further determine that the first user
is a registered user of the digital asset exchange. In embodiments,
the digital asset exchange may be licensed by a government
regulatory authority.
[0307] At step S1602C, the digital asset exchange computer system
generates first graphical user interface (GUI) information for
displaying a first graphical user interface on the first user
device. In step S1602D, the digital asset exchange computer system
transmits the first graphical user interface information to the
first user device.
[0308] Referring back to FIG. 16A, in step S1604, the digital asset
computer system obtains a withdraw request from the first user
device. FIG. 16C provides a detailed illustration of an exemplary
process of obtaining the withdraw request that may be used in
accordance with exemplary embodiments of step 1604. In step S1604A,
the digital asset exchange computer system receives a first
electronic request to withdraw stable value digital asset tokens
from the first user device. In embodiments, the stable value
digital asset token is tied to an underlying digital asset which is
maintained on a distributed public transaction ledger in the form
of a blockchain maintained by a plurality of geographically
distributed computer systems in a peer-to-peer network in the form
of the blockchain network. In embodiments, the underlying digital
asset is ether and the blockchain is the Ethereum Blockchain. In
embodiments, the underlying digital asset is neo and the blockchain
is the Neo Blockchain.
[0309] In step S1604B, the digital asset exchange computer system
obtains first account balance information of the first user
indicating a first amount of available fiat for the first user held
by the digital asset exchange on behalf of the user. The digital
asset exchange computer system may obtain the first account balance
from a fiat account ledger database stored on computer readable
member accessible by the digital asset exchange computer
system.
[0310] In step S1604C, the digital asset exchange computer system
generates second graphical user interface information including at
least the first account balance information. In embodiments, the
second graphical user interface may be similar to the graphical
user interface shown in connection with FIG. 15B. In step S1604D,
the digital asset exchange computer system transmits the second
graphical user interface information to the first user device. In
embodiments, the first user device may display the second graphical
user interface in response to this transmission. For example, the
first user device may display the graphical user interface shown in
connection with FIG. 15B.
[0311] In step S1604E, the digital asset exchange computer system
receives a second electronic withdrawal request from the first user
device. The second electronic withdrawal request may comprise at
least: (1) a first amount of stable value digital asset tokens to
be withdrawn; and (2) a destination public address on the
underlying blockchain to transfer the first amount of stable value
digital asset tokens.
[0312] Referring back to FIG. 16A, in step S1606, the digital asset
exchange computer system processes the second withdrawal request.
FIGS. 16D-16E provide a detailed illustration of an exemplary
process of processing the second withdrawal request that may be
used In embodiments, of step S1606. In step S1606A, the digital
asset exchange computer system calculates a second amount of fiat
based on the first amount of stable value digital asset tokens. The
second amount of fiat may be determined using a fixed predetermined
ratio of stable value digital asset tokens to fiat. In embodiments,
the fiat is U.S. Dollars. In the embodiments where the fiat is U.S.
Dollars, the fixed predetermined ratio may be one stable value
digital asset token is equal to one U.S. Dollar. In embodiments,
the ratio may be one hundred stable value digital asset tokes is
equal to one U.S. Dollar.
[0313] At step S1606B, the digital asset exchange computer system
determines that the second amount of fiat is less than the first
amount of available fiat of the first user. In step 1606C, where
the second amount of fiat is less than the first amount of
available fiat of the first user, the digital asset exchange
computer system determines a third amount of fiat associated with
an updated amount of available fiat of the first user. In
embodiments, the third amount of fiat equals the first amount of
available fiat of the first user less the second amount of
fiat.
[0314] In step S1606D, the digital asset exchange computer system
updates the fiat ledger database to reflect the updated amount of
available fiat. In step S1606E, the digital asset exchange computer
system updates a stable value digital asset token issuer fiat
ledger, increasing the balance of fiat by the second amount of
fiat. In embodiments, the digital asset exchange computer system
may transfer the second amount of fiat from a digital asset
exchange fiat account to a stable value digital asset token issuer
fiat account. In embodiments, the digital asset exchange computer
system may periodically transfer fiat between the digital asset
exchange fiat account and the stable value digital asset token
issuer fiat account.
[0315] In step S1606F, the digital asset exchange computer system
generates a first transaction request for the blockchain network
from a first digital asset exchange public key address on the
blockchain to a first contract address associated with a stable
value digital asset token issuer. In embodiments, the first digital
asset exchange public key is mathematically related to a first
digital asset exchange private key which is stored in the computer
readable member accessible by the digital asset exchange computer
system. The first transaction request may comprise a first message
including a request to obtain in the first designated public
address the first amount of stable value digital asset tokens. In
embodiments, the first transaction request is signed with a digital
signature generated using at least the digital asset exchange
private key. In embodiments, the request to obtain may further
include a request to generate the first amount of stable value
digital asset tokens at the first designated public address of the
first user. In embodiments, the request to obtain may include a
request to transfer the first amount of stable value digital asset
tokens from a stable value digital asset token issuer public
address to the first designated public address of the first
user.
[0316] In step S1606G of FIG. 16E, the digital asset exchange
computer system transmits the first transaction request to the
blockchain network via the Internet. In step S1606H, the digital
asset exchange computer system confirms, via reference to the
blockchain, that the balance of stable value digital asset tokens
in the first designated public address of the first user includes
the first amount of stable value digital asset tokens.
[0317] In embodiments, as noted above, customers may exchange U.S.
dollars for Gemini Dollar tokens at a 1:1 exchange rate, for
example, by initiating a withdrawal of Gemini Dollar tokens from
their digital asset exchange account to any Ethereum address they
specify, as indicated in FIG. 15B. The U.S. dollar amount of Gemini
Dollar tokens will be debited from the customer's exchange account
balance at the time of withdrawal.
[0318] In embodiments, as illustrated in FIG. 15C, for example, the
exemplary dashboard may also allow the user an opportunity to
cancel a transaction before final execution by the blockchain
network and inclusion on the underlying blockchain.
[0319] In Step S1002 of FIG. 10, for example, Alice's wallet, or
associated digital asset address, may send a request message to the
database maintained by the blockchain including: (a) Alice's
digital signature, which is based on Alice's private key which
corresponds to her public key which is associated with her ethereum
digital asset address (her public address), which is typically
associated with a digital wallet (Source Address); (b) token
identification information; (c) amount of token to be transferred;
and (d) Bob's ethereum digital asset address (Destination Address).
In embodiments, if a fee is charged for the transaction, fee
payment information may also be required and provided. For example,
on the Ethereum network, an amount of Gas tokens may be required
from the sender to pay for processing of the transaction into a
block on the blockchain. In embodiments, the message may include a
proposed fee amount and/or fee proposal including a limit in e.g.,
Gas. The request message will also be digitally signed by Alice's
private key.
[0320] In Step S1004, when miners on the blockchain network receive
the transaction request directed to the contract wallet or
associated digital asset address, with the request message, miners
on the blockchain network will confirm the transaction, including
verifying that the message was properly signed by Alice's digital
signature. In Step S1004-b, the miners may verify that Alice has
sufficient amount of tokens to perform the requested transaction,
for example, by comparing Alice's balance against Alice's token
balance as indicated on the blockchain. In Step S1004-c, the
validity of Bob's digital asset address (the Destination Address)
may also be confirmed by the miners. The miners may also compare
the request with smart contract coding and instructions included in
the Contract Address. The transaction fee discussed above is paid
to the miners for confirming the transaction as noted above.
[0321] In Step S1006, if the request is verified the transaction is
published in the Security Token database of the blockchain
reflecting a debit against Alice's token holdings and a
corresponding credit to Bob's token holdings (less any applicable
fees).
[0322] In Step S1008, response messages to the digital asset
addresses of both Alice and Bob may be sent to reflect that the
transaction was successfully processed. In embodiments, such
messages may include information including: (i) the source digital
asset address; (ii) the destination digital asset address; (iii)
the amount of tokens transferred; and/or (iv) the new balances for
each digital asset address or associated digital wallet. In
embodiments, the message may include a proposed fee amount and/or
fee proposal including a limit in e.g., Gas. In embodiments, Alice,
Bob, and/or third parties may view the balances and transaction
information based on the information stored in the blockchain, by,
e.g., viewing token balances at websites like etherscan.io, to name
a few.
[0323] In contrast to tokens, a blockchain based digital asset
(such as ether) is hard coded into the blockchain (e.g., the
Ethereum Blockchain) itself. It is sold and traded as a
cryptocurrency, and it also powers the network (e.g., the Ethereum
Network) by allowing users to pay for smart contract transaction
fees. In some networks, transactions fees may be paid for in
digital assets, such as tokens (e.g., Gas) or blockchain based
digital assets (e.g., bitcoin). In the Ethereum Network, all
computations typically have a cost based on other digital assets,
such as Gas.
[0324] In embodiments, when tokens are sent to or from a Contract
Address, for example, a fee may be charged for that transaction (in
this case, a request to the token's contract to update its
database) in, e.g., some form of digital asset, such as ether,
bitcoin, Gas, to name a few. In embodiments, the message may
include a proposed fee amount and/or fee proposal including a limit
in digital asset, e.g., ether, bitcoin or Gas. This payment is then
collected by a miner who confirms the transaction in a block, which
then gets added to the blockchain.
[0325] FIG. 2 is an exemplary screen shot of an excerpt of a
bitcoin transaction log or transaction ledger 115 showing digital
asset account identifiers (e.g., addresses) corresponding to origin
and destination accounts for each transaction and amount
information for each transaction in accordance with exemplary
embodiments of the present invention. The exemplary log 115
includes transaction identifiers, date and/or time information, fee
information, digital asset account identifiers for the origin
accounts, digital asset account identifiers for the destination
accounts, and amounts transferred to and from each account. Such a
ledger may also include description information (such as notes
describing a transaction, e.g. "rent payment") and/or balance
information, to name a few. Other forms of transaction logs can be
used consistent with exemplary embodiments of the present
invention. In an exemplary embodiment, the description information
may be included as a message in a request for a transaction. The
description information discussed above thus may also be used to
confirm control of over a particular account.
[0326] As can be seen in FIG. 2, digital asset transfers may begin
from a single origin and be sent to a single destination or
multiple destinations. Similarly, digital assets may be transferred
from multiple origins to one or more destinations.
[0327] FIG. 2A illustrates a screenshot showing an exemplary
embodiment of a token ledger for a Gas token. This particular
screenshot shows a specific example the token ledger for the Gas
token provided by etherscan.io. As illustrated the ledger
illustrates, in chronological order, a series of transactions
identifying the source address 2202 and destination address 2204
along with the quantity of tokens 2206 transferred in each
transaction. In embodiments, the Security Token ledger of the
present application may be similar to that illustrated in FIG. 2A.
In embodiments, as illustrated in FIG. 2A, the Security Token
ledger may also include the option to identify all Token holders
2208 as well as options to view token details 2210 and to view the
contract details 2012. Similarly, in embodiments, an SVCoin Token
ledger of the present application may be similar to that
illustrated in FIG. 2A. Digital asset ledgers may be maintained in
the form of a database. Such a database may be maintained on a
blockchain or off a blockchain as a sidechain which may later be
published to the blockchain.
[0328] An exemplary embodiment of a digital asset network is
illustrated in FIG. 1. In embodiments, other digital math-based
assets can be maintained and/or administered by other digital
math-based asset networks. Without meaning to limit the invention,
a digital math-based asset network will be discussed with reference
to a Bitcoin network by example. Of course, other digital asset
networks, such as the Ethereum network can be used with embodiments
of the present invention. A digital math-based asset network, such
as a Bitcoin network, may be an on-line, end-user to end-user
network hosting a public transaction ledger 115 and governed by
source code 120' comprising cryptologic and/or algorithmic
protocols. A digital asset network can comprise a plurality of end
users, a . . . N, each of which may access the network using one or
more corresponding user device 105a, 105b, . . . 105N. In
embodiments, user devices 105a, 105b, . . . 105N may be operatively
connected to each other through a data network 125, such as the
Internet, a wide area network, a local area network, a telephone
network, dedicated access lines, a proprietary network, a satellite
network, a wireless network, a mesh network, or through some other
form of end-user to end-user interconnection, which may transmit
data and/or other information. Any participants in a digital asset
network may be connected directly or indirectly, as through the
data network 125, through wired, wireless, or other
connections.
[0329] In the exemplary embodiment, user devices 105a, 105b, . . .
105N can each run a digital asset client 110, e.g., a Bitcoin
client, which can comprise digital asset source code 120 and an
electronic transaction ledger 115. The source code 120 can be
stored in processor readable memory, which may be accessed by
and/or run on one or more processors. The electronic transaction
ledger 115 can be stored on the same and/or different processor
readable memory, which may be accessible by the one or more
processors when running the source code 120. In embodiments, the
electronic transaction ledger 115a (contained on a user device
105a) should correspond with the electronic transaction ledgers
115b . . . 115N (contained on user devices 105b . . . 105N), to the
extent that the corresponding user device has accessed the Internet
and been updated (e.g., downloaded the latest transactions).
Accordingly, the electronic transaction ledger may be a public
ledger. Exemplary embodiments of digital asset clients 110 for the
Bitcoin network (Bitcoin clients) include Bitcoin-Qt and Bitcoin
Wallet, to name a few.
[0330] In embodiments, some of the transactions on the public
ledger may be encrypted or otherwise shielded so that only
authorized users may access ledger information about such
transactions or wallets.
[0331] In addition, a digital asset network, such as a Bitcoin
network, may include one or more digital asset exchange 130, such
as Bitcoin exchanges (e.g., BitFinex, BTC-e). Digital asset
exchanges may enable or otherwise facilitate the transfer of
digital assets, such as bitcoin, and/or conversions involving
digital assets, such as between different digital assets and/or
between a digital asset and non-digital assets, currencies, to name
a few. The digital asset network may also include one or more
digital asset exchange agents 135, e.g., a Bitcoin exchange agent.
Exchange agents 135 may facilitate and/or accelerate the services
provided by the exchanges. Exchanges 130, transmitters 132, and/or
exchange agents 135 may interface with financial institutions
(e.g., banks) and/or digital asset users. Transmitters 132 can
include, e.g., money service businesses, which could be licensed in
appropriate geographic locations to handle financial transactions.
In embodiments, transmitters 132 may be part of and/or associated
with a digital asset exchange 130. Like the user devices 105,
digital asset exchanges 130, transmitters 132, and exchange agents
135 may be connected to the data network 125 through wired,
wireless, or other connections. They may be connected directly
and/or indirectly to each other and/or to one or more user device
105 or other entity participating in the digital asset system.
[0332] Digital assets may be sub-divided into smaller units or
bundled into blocks or baskets. For example, for bitcoin, subunits,
such as a Satoshi, as discussed herein, or larger units, such as
blocks of bitcoin, may be used in exemplary embodiments. Each
digital asset, e.g., bitcoin, may be subdivided, such as down to
eight decimal places, forming 100 million smaller units. For at
least bitcoin, such a smaller unit may be called a Satoshi. Other
forms of division can be made consistent with embodiments of the
present invention.
[0333] In embodiments, the creation and transfer of digital
math-based assets can be based on an open source mathematical
and/or cryptographic protocol, which may not be managed by any
central authority. Digital assets can be transferred between one or
more users or between digital asset accounts and/or storage devices
(e.g., digital wallets) associated with a single user, through a
network, such as the Internet, via a computer, smartphone, or other
electronic device without an intermediate financial institution. In
embodiments, a single digital asset transaction can include amounts
from multiple origin accounts transferred to multiple destination
accounts. Accordingly, a transaction may comprise one or more input
amounts from one or more origin digital asset accounts and one or
more output amounts to one or more destination accounts. Origin and
destination may be merely labels for identifying the role a digital
asset account plays in a given transaction; origin and destination
accounts may be the same type of digital asset account.
[0334] In embodiments, a digital math-based asset system may
produce digital asset transaction change. Transaction change refers
to leftover digital asset amounts from transactions in digital
asset systems, such as Bitcoin, where the transactions are
comprised of one or more digital inputs and outputs. A digital
asset account can store and/or track unspent transaction outputs,
which it can use as digital inputs for future transactions. In
embodiments, a wallet, third-party system, and/or digital asset
network may store an electronic log of digital outputs to track the
outputs associated with the assets contained in each account. In
digital asset systems such as Bitcoin, digital inputs and outputs
cannot be subdivided. For example, if a first digital asset account
is initially empty and receives a transaction output of 20 BTC (a
bitcoin unit) from a second digital asset account, the first
account then stores that 20 BTC output for future use as a
transaction input. To send 15 BTC, the first account must use the
entire 20 BTC as an input, 15 BTC of which will be a spent output
that is sent to the desired destination and 5 BTC of which will be
an unspent output, which is transaction change that returns to the
first account. An account with digital assets stored as multiple
digital outputs can select any combination of those outputs for use
as digital inputs in a spending transaction. In embodiments, a
digital wallet may programmatically select outputs to use as inputs
for a given transaction to minimize transaction change, such as by
combining outputs that produce an amount closest to the required
transaction amount and at least equal to the transaction
amount.
[0335] Referring again to FIG. 1, a digital asset network may
include digital asset miners 145. Digital asset miners 145 may
perform operations associated with generating or minting new
digital assets, and/or operations associated with confirming
transactions, to name a few. Digital asset miners 145 may
collaborate in one or more digital asset mining pools 150, which
may aggregate power (e.g., computer processing power) so as to
increase output, increase control, increase likelihood of minting
new digital assets, increase likelihood of adding blocks to a
blockchain, to name a few.
[0336] In embodiments, the processing of digital asset
transactions, e.g., bitcoin transactions, can be performed by one
or more computers over a distributed network, such as digital asset
miners 145, e.g., bitcoin miners, and/or digital asset mining pools
150, e.g., bitcoin mining pools. In embodiments, mining pools 150
may comprise one or more miners 145, which miners 145 may work
together toward a common goal. Miners 145 may have source code
120', which may govern the activities of the miners 145. In
embodiments, source code 120' may be the same source code as found
on user devices 105. These computers and/or servers can communicate
over a network, such as an internet-based network, and can confirm
transactions by adding them to a ledger 115, which can be updated
and archived periodically using peer-to-peer file sharing
technology. For example, a new ledger block could be distributed on
a periodic basis, such as approximately every 10 minutes. In
embodiments, the ledger may be a blockchain. Each successive block
may record transactions that have occurred on the digital asset
network. In embodiments, all digital asset transactions may be
recorded as individual blocks in the blockchain. Each block may
contain the details of some or all of the most recent transactions
that are not memorialized in prior blocks. Blocks may also contain
a record of the award of digital assets, e.g., bitcoin, to the
miner 145 or mining pool 150 who added the new block, e.g., by
solving calculations first.
[0337] A miner 145 may have a calculator 155, which may solve
equations and/or add blocks to the blockchain. The calculator 155
may be one or more computing devices, software, or special-purpose
device, to name a few. In embodiments, in order to add blocks to
the blockchain, a miner 145 may be required to map an input data
set (e.g., the blockchain, plus a block of the most recent
transactions on the digital asset network, e.g., transactions on
the Bitcoin network, and an arbitrary number, such as a nonce) to a
desired output data set of predetermined length, such as a hash
value. In embodiments, mapping may be required to use one or more
particular cryptographic algorithms, such as the SHA-256
cryptographic hash algorithm or scrypt, to name a few. In
embodiments, to solve or calculate a block, a miner 145 may be
required to repeat this computation with a different nonce until
the miner 145 generates a SHA-256 hash of a block's header that has
a value less than or equal to a current target set by the digital
asset network. In embodiments, each unique block may only be solved
and added to the blockchain by one miner 145. In such an
embodiment, all individual miners 145 and mining pools 150 on the
digital asset network may be engaged in a competitive process and
may seek to increase their computing power to improve their
likelihood of solving for new blocks. In embodiments, successful
digital asset miners 145 or mining pools 150 may receive an
incentive, such as, e.g., a fixed number of digital assets (e.g.,
bitcoin) and/or a transaction fee for performing the calculation
first and correctly and/or in a verifiable manner.
[0338] In embodiments, the cryptographic hash function that a miner
145 uses may be one-way only and thus may be, in effect,
irreversible. In embodiments, hash values may be easy to generate
from input data, such as valid recent network transaction(s),
blockchain, and/or nonce, but neither a miner 145 nor other
participant may be able to determine the original input data solely
from the hash value. Other digital asset networks may use different
proof of work algorithms, such as a sequential hard memory
function, like scrypt, which may be used for Litecoin. As a result,
generating a new valid block with a header less than the target
prescribed by the digital asset network may be initially difficult
for a miner 145, yet other miners 145 can easily confirm a proposed
block by running the hash function at least once with a proposed
nonce and other identified input data. In embodiments, a miner's
proposed block may be added to the blockchain once a defined
percentage or number of nodes (e.g., a majority of the nodes) on
the digital asset network confirms the miner's work. A miner 145
may have a verifier 160, which may confirm other miners' work. A
verifier 160 may be one or more computers, software, or specialized
device, to name a few. A miner 145 that solved such a block may
receive the reward of a fixed number of digital assets and/or any
transaction fees paid by transferors whose transactions are
recorded in the block. "Hashing" may be viewed as a mathematical
lottery where miners that have devices with greater processing
power (and thus the ability to make more hash calculations per
second) are more likely to be successful miners 145. In
embodiments, as more miners 145 join a digital asset network and as
processing power increases, the digital asset network may adjust
the complexity of the block-solving equation to ensure that one
newly-created block is added to the blockchain approximately every
ten minutes. Digital asset networks may use different processing
times, e.g., approximately 2.5 minutes for Litecoin, approximately
10 minutes for Bitcoin, to name a few.
[0339] In addition to archiving transactions, a new addition to a
ledger can create or reflect creation of one or more newly minted
digital assets, such as bitcoin. In embodiments, new digital
math-based assets may be created through a mining process, as
described herein. In embodiments, the number of new digital assets
created can be limited. For example, in embodiments, the number of
digital assets (e.g., bitcoin) minted each year is halved every
four years until a specified year, e.g., 2140, when this number
will round down to zero. At that time no more digital assets will
be added into circulation. In the exemplary embodiment of bitcoin,
the total number of digital assets will have reached a maximum of
21 million assets in denomination of bitcoin. Other algorithms for
limiting the total number of units of a digital math-based asset
can be used consistent with exemplary embodiments of the present
invention. For example, the Litecoin network is anticipated to
produce 84 million Litecoin. In embodiments, the number of digital
assets may not be capped and thus may be unlimited. In embodiments,
a specified number of coins may be added into circulation each
year, e.g., so as to create a 1% inflation rate.
[0340] In embodiments, the mining of digital assets may entail
solving one or more mathematical calculations. In embodiments, the
complexity of the mathematical calculations may increase over time
and/or may increase as computer processing power increases. In
embodiments, result of solving the calculations may be the addition
of a block to a blockchain, which may be a transaction ledger, as
described further below. Solving the calculations may verify a set
of transactions that has taken place. Solving the calculations may
entail a reward, e.g., a number of digital math-based assets and/or
transaction fees from one or more of the verified transactions.
[0341] Different approaches are possible for confirming
transactions and/or creating new assets. In embodiments, a digital
asset network may employ a proof of work system. A proof of work
system may require some type of work, such as the solving of
calculations, from one or more participants (e.g., miners 145) on
the network to verify transactions and/or create new assets. In
embodiments, a miner 145 can verify as many transactions as
computationally possible. A proof of work system may be
computationally and/or energy intensive. In embodiments, the
network may limit the transactions that a miner 145 may verify.
[0342] In embodiments, a digital asset network may employ a proof
of stake system. In a proof of stake system, asset ownership may be
tied to transaction verification and/or asset creation. Asset
ownership can include an amount of assets owned and/or a duration
of ownership. The duration of ownership may be measured linearly as
time passes while a user owns an asset. In an exemplary embodiment,
a user holding 4% of all digital assets in a proof of stake system
can generate 4% of all blocks for the transaction ledger. A proof
of stake system may not require the solution of complex
calculations. A proof of stake system may be less energy intensive
than a proof of work system. In embodiments, a hybrid of proof of
work and proof of stake systems may be employed. For example, a
proof of work system may be employed initially, but as the system
becomes too energy intensive, it may transition to a proof of stake
system.
[0343] Proof or work and proof of stake are both examples of
consensus algorithms. Such consensus algorithms have as their goal
providing a method of reaching consensus to improve the system
whether it be on ways of improving transactions, upgrading the
network, etc.
[0344] In embodiments, asset creation and/or transaction
confirmation can be governed by a proof of stake velocity system.
Proof of stake velocity may rely upon asset ownership where the
function for measuring duration of ownership is not linear. For
example, an exponential decay time function may ensure that assets
more newly held correspond to greater power in the system. Such a
system can incentivize active participation in the digital
math-based asset system, as opposed to storing assets
passively.
[0345] In embodiments, a proof of burn system may be employed.
Proof of burn may require destroying assets or rendering assets
unspendable, such as by sending them to an address from which they
cannot be spent. Destroying or rendering assets unusable can be an
expensive task within the digital math-based asset system, yet it
may not have external costs such as the energy costs that can be
associated with mining in a proof of work system.
[0346] Blockchains can include a consensus generating protocol
through which the network determines whether a transaction is
valid, included in the ledger and in what order each transaction
should be included. Examples of such facilities may include mining,
proof of work, proof of stake protocols, to name a few.
Stable Value Digital Asset Token
[0347] In embodiments, a stable value digital asset token, or
Stable Value Token ("SVCoin") may operate on a blockchain based
network, such as the Ethereum network, a decentralized virtual
currency and blockchain network with a programming language that
can automatically facilitate, verify, and enforce the terms of a
digital contract entered into by human or computer counterparties.
In embodiments, the SVCoin may conform with the ERC-223 token
standard, making it available for a variety of uses within the
Ethereum Network. In embodiments, the SVCoin may conform to the
ERC-721 token standard. However, unlike other types of
cryptocurrencies currently available on the Ethereum Network or the
virtual currency ecosystem generally, the SVCoin will be strictly
pegged to a fiat currency, such as the U.S. Dollar, and a
custodian, such as a trusted entity like a digital asset exchange
or bank, to name a few, will hold an equal value in fiat (e.g., one
(1) SVCoin is pegged to be equal to one (1) USD or one hundred
(100) SVCoin is pegged to equal one (1) USD, to name a few). In
embodiments, periodic or aperiodic reconciliations may be performed
to confirm that the amount of fiat currency held by the trusted
entity corresponds to the number of SVCoins (Stable Value Tokens)
held on the public ledger. In embodiments, the reconciliation may
account for the fact that SVCoins (Stable Value Tokens) may have
been created but not yet distributed to third parties.
[0348] In embodiments, a digital asset exchange, such as a
regulated digital asset exchange, like Gemini, may be the sole
issuer of the SVCoin. In embodiments, especially in the context of
a regulated digital asset exchange, in order to obtain freshly
minted SVCoin, customers must first register with the digital asset
exchange and create an exchange account to allow access to the
digital asset exchange platform. Customers may deposit fiat (e.g.,
USD) with the digital asset exchange, via, e.g., Fedwire, ACH,
Swift, to name a few, into the customers respective exchange
account, or convert into fiat some or all of existing digital
assets held at the digital asset exchange. SVCoin may be held in
the customer's exchange account or may be transferred via the
blockchain, such as via the Ethereum Network. In embodiments, the
SVCoin issuer may be a digital asset exchange, a bank, a trust or
some other trusted entity, to name a few.
[0349] In embodiments, regardless of whether the SVCoin is stored
in the customer's exchange account or transferred via the
blockchain such as the Ethereum Network, the digital exchange will
continue to hold sufficient fiat to maintain the total value of
SVCoin based on a notional pegged rate (e.g., one USD for every one
SVCoin issued). In embodiments, the value of the SVCoin is pegged
to the fiat in a fixed proportion, for example 1:1. In embodiments,
fiat will be held in a segregated, omnibus bank account at one or
more federally insured depository institution. In embodiments, the
fiat may be held in other secure and non-volatile financial
instruments, such as invested in treasury bills or other liquid,
interest bearing financial instruments.
[0350] In embodiments, customers wishing to redeem their SVCoin for
fiat may do so through the digital asset platform. Customers that
have transferred their SVCoin to the blockchain will be able to
transfer their SVCoin back to their exchange account, and
subsequently redeem them for fiat through the digital exchange
platform, such as via Fedwire, ACH or SWIFT to the customer's
registered bank account, to name a few. For each fiat redeemed with
the digital exchange, a corresponding SVCoin will be removed from
circulation. As mentioned above, exemplary embodiments of such
transactions are discussed below in connection with the description
of FIGS. 11A-1-4, 11B-1-4, and 11C-1-2.
[0351] In embodiments, the Stable Value Token may be implemented as
a token on the Ethereum blockchain, following the open standard
known as ERC20 adopted by the Ethereum community. In embodiments,
the Stable Value Token may be a system of smart contracts. In
embodiments, the Stable Value Token may be a triplet of smart
contracts on the Ethereum blockchain, which may be referred to as
`Proxy`, `Impl`, and `Store`.
[0352] In embodiments, the smart contract known as `Proxy` is the
permanent and public face of the Stable Value Token and provides
the interface to interact with the token to allow token holders
transfer their tokens and view token balances. In embodiments,
however, this contract contains neither the code nor the data that
comprises the behavior and state of the Stable Value Token.
[0353] In embodiments, the `Proxy` contract delegates to the
contract known as `Impl` authority to execute the logic that
governs token transfers, issuance, and other core features. In
embodiments, `Impl` does not directly own the data that is the
ledger of the Stable Value Token, the mapping of token holders to
their balances, but instead delegates this to the smart contract
known as `Store`.
[0354] In embodiments, the arrangement of `Proxy`, `Impl`, and
`Store` provides for future change and flexibility. While `Proxy`
may be the permanent address of the Stable Value Token on the
Ethereum blockchain, and `Store` is the external storage of the
token ledger, the `Impl` contract is designed to be replaced, if
need be. Utilizing this architecture to implement the Stable Value
Token provides for the following advantages: [0355] 1. allows for
responding to security incidents and resolving vulnerabilities;
[0356] 2. allows for extending the system with new features; [0357]
3. allows for adding later optimizations to improve the operational
efficiency of the token; and [0358] 4. In extreme cases and when
compelled to do so, allows for pause, block, or reverse token
transfers.
[0359] In embodiments, each of these three contracts may be a
custodian: an actor in the system that has the sole authority to
authorize important actions. In embodiments, the custodianship role
varies for each of `Proxy`, `Impl`, and `Store`. In embodiments,
the custodian of `Proxy` can redirect the delegation to the active
token implementation, the specific `Impl` contract. In embodiments,
matching this arrangement, the `Store` contract may only accept
updates to its ledger from a single trusted source, the active
token implementation, the specific `Impl` contract. In embodiments,
these two custodial actions on `Proxy` and `Store` provide the
upgrade feature where a new `Impl` displaces the prior version by
the custodian of `Proxy` redirecting the delegation in `Proxy`; and
a new `Impl` displaces the prior version by the custodian of
`Store` updating the trusted caller of `Store`. In embodiments, the
custodians of `Proxy` and `Store` can also pass custodianship to
new custodians.
[0360] In embodiments, the primary custodial action on the `Impl`
contract is different. In embodiments, an important aspect of the
Stable Value Tokens is governing the increase to the token supply
since at all times the system must ensure that there are at least
as many U.S. Dollars as there are Stable Value Tokens in
circulation. In embodiments, the `Impl` contract contains the logic
to increase the token supply, and the custodian of `Impl` has the
sole authority to invoke it. In embodiments, custodianship can also
be passed.
[0361] In embodiments, an auxiliary contract is a contract to
fulfill the custodian role, which we will refer to here as
`Custodian`. In embodiments, this contract is designed around
several security principles: [0362] 1. Dual Control: actions by the
`Custodian` contract are initially locked, and pending actions will
only proceed once two out of a set of designated signers approve
the action. (Approval is a digital signature linked to the action
instructions, e.g. the amount and destination of new tokens.)
[0363] 2. Offline Control: the `Custodian` contract is designed
with the expectation that the set of designated signers are keys
managed by offline ("air gapped") computer systems. [0364] 3. Time
Locks: actions by the `Custodian` contract are locked not only
pending approval from two signers, but also require the passage of
a minimum period of time before they can be executed. This enables
the effective use of intrusion detection systems and a window of
opportunity to respond to security breaches. [0365] 4. Revocation:
pending actions can be revoked; thus erroneous or malicious actions
can be nullified while they are still pending.
[0366] This provides strong security control on custodianship,
which is appropriate for the critical and infrequent system actions
of replacing the `Impl` contract ("the upgrade feature") and
passing custodianship. In embodiments, however, for the action of
increasing the token supply, an action expected to occur
frequently, using `Custodian` as the custodian of `Impl` introduces
an undue operational burden.
[0367] In embodiments, a second auxiliary contract, is referred to
as `PrintLimiter`. In embodiments, the purpose of the
`PrintLimiter` smart contract is to govern the increases to the
supply of Stable Value Tokens, specifically by a hybrid of online
and offline control. While `Custodian` is the custodian of the
contracts `Proxy` and `Store`, the `PrintLimiter` contract is the
custodian of `Impl`, and in turn, `Custodian` is the custodian of
`PrintLimiter`. In embodiments, this doubly-layered custodianship
relationship still reserves ultimate control to `Custodian`,
however, the `PrintLimiter` contract grants limited permission to
increase the token supply ("print" new tokens) to a key in online
control (an automated, networked computer system), which we will
refer to as `printer`. In embodiments, the `printer` key can
increase the token supply in response to user demand to withdraw
U.S. dollars as Stable Value Tokens, but only up until a ceiling.
In embodiments, further expansion of the supply is disallowed by
`PrintLimiter` once the ceiling is reached. In embodiments,
increasing the ceiling is an action reserved for the custodian, and
the custodian of `PrintLimiter` is `Custodian.` In embodiments, the
`printer` can reduce the ceiling thus reducing its own grant. In
embodiments, offline control can increase the grant to online
control; online control can decrease its own grant. In embodiments,
the `Print Limiter` smart contract may include instructions
requiring authorization of multiple keys to increase the supply of
Stable Value Tokens. In embodiments, the multiple keys may require
at least two signers. This could include using a M of N model,
where M is at least 2 and N is equal to or greater than M (e.g., 2
or more, when M is 2). Thus, in embodiments, multiple keys may
include a set number of keys of a set number of possible keys, for
example, two keys of a possible three keys. In embodiments, the
multiple keys may require all keys of possible keys, for example,
three keys of a possible three keys. In embodiments, the
arrangement discussed herein achieves a hybrid of online and
offline control over the supply of Stable Value Tokens. In
embodiments, tokens can be issued in an efficient and timely
manner, while the risk of inflation of the supply of Stable Value
Tokens without backing U.S. Dollars is bounded.
[0368] In embodiments, as noted above, multiple signatures may be
required for certain transactions such as those requiring
intervention of the Custodian 1350. In embodiments, as noted above,
changing the implementation pointer from ERC20Proxy 1310 which is
currently set at S1312 (impl) to point to ERC20Impl 1320 (Version
1), requires resetting S1312B "impl" to point to ERC20Impl 1320A
(version 2). In embodiments, a request is made to ERC20Proxy to
change its instance of ERC20Impl. When the request is made, a
unique lockId is generated. In embodiments, the Custodian contract
1350 for ERC20 Proxy 1310 calls requestUnlock and passes as
arguments the lockId generated for the change request, and the
function in ERC20Proxy 1310 the Custodian 1350 needs to call to
confirm the change request. This generates a request, which is a
unique identifier for this unlock request.
[0369] In embodiments, to complete the unlocking of Custodian and
therefore propagate the change to ERC20Proxy 1310, the digital
asset system operated by the token issuer uses its off-line key
storage infrastructure to sign the request with the previously
approved designated key sets. This may require the use of two or
more key sets.
[0370] In embodiments, those signatures are passed into the
Custodian's completeUnlock function along with the initial request.
Once the request is validated against the signatures,
completeUnlock parses the content of the request and issues the
command. In this exemplary case, ERC20Proxy's confirmImplChange is
called using the lockId generated in the initial ERC20Impl change
request.
[0371] In embodiments, the arrangement discussed herein achieves a
hybrid of online and offline control over the supply of Stable
Value Tokens. In embodiments, tokens can be issued in an efficient
and timely manner, while the risk of inflation of the supply of
Stable Value Tokens without the backing of U.S. Dollars is bounded.
In embodiments, pending actions may be revoked, allowing for the
nullification of erroneous or malicious actions before being
executed.
[0372] A method of withdrawing stable value digital asset tokens
based on an underlying digital asset from a digital asset exchange
computer system in exchange for fiat, in accordance with an
embodiment of the present application includes: (a) authenticating,
by the digital asset exchange computer system associated with a
digital asset exchange, an access request by a first user device
associated with a first user, to the digital asset exchange
computer system comprising the steps of: (1) receiving, by the
digital asset exchange computer system from the first user device,
an authentication request including first user credential
information associated with the first user; (2) determining, by the
digital asset exchange computer system, that the first user device
is authorized to access the digital asset exchange computer system
based at least in part on the first user credential information;
(3) generating, by the digital asset exchange computer system,
first graphical user interface information for displaying a first
graphical user interface on the first user device; (4)
transmitting, from the digital asset exchange computer system to
the first user device, the first graphical user interface
information; (b) obtaining, by the digital asset computer system
from the first user device, a withdraw request comprising the steps
of: (1) receiving, by the digital asset exchange computer system
from the first user device, a first electronic request to withdraw
stable value digital asset tokens, wherein the stable value digital
asset token is tied to an underlying digital asset which is
maintained on a distributed public transaction ledger in the form
of a blockchain that is maintained by a blockchain network
including a plurality of geographically distributed computer
systems in a peer-to-peer network; (2) in response to the first
electronic request, obtaining, by the digital asset exchange
computer system from a fiat account ledger database stored on
computer readable member accessible by the digital asset exchange
computer system, first account balance information of the first
user indicating a first amount of available fiat for the first user
held by the digital asset exchange on behalf of the first user; (3)
generating, by the digital asset exchange computer system, second
graphical user interface information including at least the first
account balance information; (4) transmitting, by the digital asset
exchange computer system to the first user device, the second
graphical user interface information; (5) receiving, by the digital
asset exchange computer system from the first user device, a second
electronic withdrawal request comprising at least: (A) a first
amount of stable value digital asset tokens to be withdrawn; and
(B) a destination public address on the underlying blockchain to
transfer the first amount of stable value digital asset tokens; (c)
processing, by the digital asset exchange computer system, the
withdraw request by the steps of: (1) calculating, by the digital
asset exchange computer system, a second amount of fiat based on
the first amount of stable value digital asset tokens, where the
second amount of fiat is determined using a fixed predetermined
ratio of stable value digital asset tokens to fiat; (2)
determining, by the digital asset exchange computer system, that
the second amount of fiat is less than the first amount of
available fiat of the first user; (3) in the case where the second
amount of fiat is less than the first amount of available fiat of
the first user, determining a third amount of fiat associated with
an updated amount of available fiat of the first user, wherein the
third amount of fiat equals the first amount of available fiat of
the first user less the second amount of fiat; (4) updating, by the
digital asset exchange computer system, the fiat account ledger
database to reflect that the updated amount of available fiat of
the first user is the third amount of fiat; (5) updating, by the
digital asset exchange computer system, a stable value digital
asset token issuer fiat ledger, to increase a balance of fiat by
the second amount of fiat; (6) generating, by the digital asset
exchange computer system, a first transaction request for the
blockchain, from a first digital asset exchange public key address
on the blockchain, which is mathematically related to a first
digital asset exchange private key, which is stored in the computer
readable member accessible by the digital asset exchange computer
system, to a first contract address associated with a stable value
token issuer, a first message including: i. a request to obtain in
the first designated public address of the first user the first
amount of stable value digital asset tokens; and wherein the first
transaction request is signed with a digital signature generated
using the digital asset exchange private key; (7) transmitting, by
the digital asset exchange computer system to the blockchain
network via the Internet, the first transaction request; (8)
confirming, by the digital asset exchange computer system by
reference to the blockchain, that the balance of stable value
digital asset tokens in the first designated public address of the
first user includes the first amount of stable value digital asset
tokens.
[0373] In embodiments, the determining step (a) (c) further
determines that the first user is a registered user of the digital
asset exchange.
[0374] In embodiments, the digital asset exchange is licensed by a
government regulatory authority.
[0375] In embodiments, the underlying digital asset is ether and
the blockchain is the Ethereum Blockchain.
[0376] In embodiments, the underlying digital asset is neo and the
blockchain is the Neo Blockchain.
[0377] In embodiments, the fixed predetermined ratio is one stable
value digital asset token is equal to one U.S. dollar.
[0378] In embodiments, the fixed predetermined ratio is one hundred
stable value digital asset tokens is equal to one U.S. dollar.
[0379] In embodiments, the updating step (c) (5) further comprises
transferring the second amount of fiat from a digital asset
exchange fiat account to a stable value digital asset token issuer
fiat account.
[0380] In embodiments, the updating step (c) (5) further comprises
periodically transferring fiat between the digital asset exchange
fiat account and the stable value digital asset token issuer fiat
account.
[0381] In embodiments, the instructions to obtain in the first
designated public address of the first user the first amount of
stable value digital asset tokens include instructions to generate
the first amount of stable value digital asset tokens at the first
designated public address of the first user.
[0382] In embodiments, the instructions to obtain in the first
designated public address of the first user the first amount of
stable value digital asset tokens include instructions to transfer
the first amount of stable value digital asset tokens from a stable
value digital asset token issuer public address to the first
designated public address of the first user.
[0383] A method of depositing stable value digital asset tokens
based on an underlying digital asset into a digital asset exchange
computer system in exchange for fiat in accordance with another
embodiment of the present application includes: (a) authenticating,
by the digital asset exchange computer system associated with a
digital asset exchange, an access request by a first user device
associated with a first user, to the digital asset exchange
computer system comprising the steps of: (1) receiving, by the
digital asset exchange computer system from the first user device,
an authentication request including first user credential
information associated with the first user; (2) determining, by the
digital asset exchange computer system, that the first user device
is authorized to access the digital asset exchange computer system
based at least in part on the first user credential information;
(3) generating, by the digital asset exchange computer system,
first graphical user interface information for displaying a first
graphical user interface on the first user device; (4)
transmitting, from the digital asset exchange computer system to
the first user device, the first graphical user interface
information; (b) obtaining, by the digital asset computer system
from the first user device, a deposit request comprising the steps
of: (1) receiving, by the digital asset exchange computer system
from the first user device, a first electronic request to deposit
stable value digital asset tokens, wherein the stable value digital
asset token is tied to an underlying digital asset which is
maintained on a distributed public transaction ledger in the form
of a blockchain that is maintained by a blockchain network
including a plurality of geographically distributed computer
systems in a peer-to-peer network; (2) in response to the first
electronic request, obtaining, by the digital asset exchange
computer system from a fiat account ledger database stored on
computer readable member accessible by the digital asset exchange
computer system, first account balance information of the first
user indicating a first amount of available fiat for the first user
held by the digital asset exchange on behalf of the first user; (3)
obtaining, by the digital asset exchange computer system, a user
specific destination address, uniquely associated with the first
user; (4) generating, by the digital asset exchange computer
system, second graphical user interface information including at
least the first account balance information and the user specific
destination address; (5) transmitting, by the digital asset
exchange computer system to the first user device, the second
graphical user interface information; (6) receiving, by the digital
asset exchange computer system from the first user device, a second
electronic deposit request comprising at least: (A) a first amount
of stable value digital asset tokens to be deposited; and (B) a
designated public address of the first user on the underlying
blockchain from which the first amount of stable value digital
asset tokens will be transferred; (C) a digital signature based on
a designated private key of the first user, wherein the designated
private key is mathematically related to the designated public
address; (c) processing, by the digital asset exchange computer
system, the second electronic deposit request by the steps of: (1)
calculating, by the digital asset exchange computer system, a
second amount of fiat based on the first amount of stable value
digital asset tokens, where the second amount of fiat is determined
using a fixed predetermined ratio of stable value digital asset
tokens to fiat; (2) determining, by the digital asset exchange
computer system, that the first amount of stable value digital
asset tokens is present at the designated public address of the
first user; (3) in the case where the first amount of stable value
digital asset tokens is present at the designated public address of
the first user, determining a third amount of fiat associated with
an updated amount of available fiat of the first user, wherein the
third amount of fiat equals the first amount of available fiat of
the first user plus the second amount of fiat; (4) updating, by the
digital asset exchange computer system, the fiat account ledger
database to reflect that the updated amount of available fiat of
the first user is the third amount of fiat; (5) generating, by the
digital asset exchange computer system, a first transaction request
for the blockchain, from a first digital asset exchange public key
address on the blockchain, which is mathematically related to a
first digital asset exchange private key, which is stored in the
computer readable member accessible by the digital asset exchange
computer system, to a first contract address associated with a
stable value token issuer, a first message including: i. a request
to obtain, from the first designated public address of the first
user, the first amount of stable value digital asset tokens from
the designated public address of the first user and provide the
first amount of stable value digital asset tokens to the user
specific destination address; and ii. a request to destroy the
first amount of stable value digital asset tokens; wherein the
first transaction request is signed with a digital signature
generated based on the digital asset exchange private key of the
user digital asset exchange; (6) updating, by the digital asset
exchange computer system, a stable value digital asset token issuer
fiat ledger, to decrease a balance of fiat by the second amount of
fiat; (7) transmitting, by the digital asset exchange computer
system to the blockchain network via the Internet, the first
transaction request; (8) confirming, by the digital asset exchange
computer system by reference to the blockchain, that the first
amount of stable value digital asset tokens are not present at the
designated public address of the first user.
[0384] In embodiments, the determining step (a) (2) further
determines that the first user is a registered user of the digital
asset exchange.
[0385] In embodiments, the digital asset exchange is licensed by a
government regulatory authority.
[0386] In embodiments, the underlying digital asset is ether and
the blockchain is the Ethereum Blockchain.
[0387] In embodiments, the underlying digital asset is neo and the
blockchain is the Neo Blockchain.
[0388] In embodiments, the fixed predetermined ratio is one stable
value digital asset token is equal to one U.S. dollar.
[0389] In embodiments, the fixed predetermined ratio is one hundred
stable value digital asset tokens is equal to one U.S. dollar.
[0390] In embodiments, the updating step (c) (6) further comprises
transferring the second amount of fiat from a digital asset
exchange fiat account to a stable value digital asset token issuer
fiat account.
[0391] In embodiments, the updating step (c) (6) further comprises
periodically transferring fiat between the digital asset exchange
fiat account and the stable value digital asset token issuer fiat
account.
[0392] A method of depositing stable value digital asset tokens
based on an underlying digital asset into a digital asset exchange
computer system in exchange for fiat in accordance with an
embodiment of the present application includes: (a) authenticating,
by the digital asset exchange computer system associated with a
digital asset exchange, an access request by a first user device
associated with a first user, to the digital asset exchange
computer system comprising the steps of: (1) receiving, by the
digital asset exchange computer system from the first user device,
an authentication request including first user credential
information associated with the first user; (2) determining, by the
digital asset exchange computer system, that the first user device
is authorized to access the digital asset exchange computer system
based at least in part on the first user credential information;
(3) generating, by the digital asset exchange computer system,
first graphical user interface information for displaying a first
graphical user interface on the first user device; (4)
transmitting, from the digital asset exchange computer system to
the first user device, the first graphical user interface
information; (b) obtaining, by the digital asset computer system
from the first user device, a deposit request comprising the steps
of: (1) receiving, by the digital asset exchange computer system
from the first user device, a first electronic request to deposit
stable value digital asset tokens, wherein the stable value digital
asset token is tied to an underlying digital asset which is
maintained on a distributed public transaction ledger in the form
of a blockchain that is maintained by a blockchain network
including a plurality of geographically distributed computer
systems in a peer-to-peer network; (2) in response to the first
electronic request, obtaining, by the digital asset exchange
computer system from a fiat account ledger database stored on
computer readable member accessible by the digital asset exchange
computer system, first account balance information of the first
user indicating a first amount of available fiat for the first user
held by the digital asset exchange on behalf of the first user; (3)
obtaining, by the digital asset exchange computer system, a user
specific destination address, uniquely associated with the first
user; (4) generating, by the digital asset exchange computer
system, second graphical user interface information including at
least the first account balance information and the user specific
destination address; (5) transmitting, by the digital asset
exchange computer system to the first user device, the second
graphical user interface information; (6) receiving, by the digital
asset exchange computer system from the first user device, a second
electronic deposit request comprising at least: (A) a first amount
of stable value digital asset tokens to be deposited; and (B) a
designated public address of the first user on the underlying
blockchain from which the first amount of stable value digital
asset tokens will be transferred; (C) a digital signature based on
a designated private key of the first user, wherein the designated
private key is mathematically related to the designated public
address; (c) processing, by the digital asset exchange computer
system, the second electronic deposit request by the steps of: (1)
calculating, by the digital asset exchange computer system, a
second amount of fiat based on the first amount of stable value
digital asset tokens, where the second amount of fiat is determined
using a fixed predetermined ratio of stable value digital asset
tokens to fiat; (2) determining, by the digital asset exchange
computer system, that the first amount of stable value digital
asset tokens is present at the designated public address of the
first user; (3) in the case where the first amount of stable value
digital asset tokens is present at the designated public address of
the first user, determining a third amount of fiat associated with
an updated amount of available fiat of the first user, wherein the
third amount of fiat equals the first amount of available fiat of
the first user plus the second amount of fiat; (4) updating, by the
digital asset exchange computer system, the fiat account ledger
database to reflect that the updated amount of available fiat of
the first user is the third amount of fiat; (5) generating, by the
digital asset exchange computer system, a first transaction request
for the blockchain, from a first digital asset exchange public key
address on the blockchain, which is mathematically related to a
first digital asset exchange private key, which is stored in the
computer readable member accessible by the digital asset exchange
computer system, to a first contract address associated with a
stable value token issuer, a first message including: i. a request
to obtain from the first designated public address of the first
user the first amount of stable value digital asset tokens from the
designated public address of the first user and provide them to the
user specific destination address; ii. a request to store the first
amount of stable value digital asset tokens at the user specific
destination address; and wherein the first transaction request is
signed with a digital signature generated based on the digital
asset exchange private key of the user digital asset exchange; (6)
transmitting, by the digital asset exchange computer system to the
blockchain network via the Internet, the first transaction request;
(7) confirming, by the digital asset exchange computer system by
reference to the blockchain, that the first amount of stable value
digital asset tokens are not present at the designated public
address of the first user.
[0393] In embodiments, the determining step (a) (2) further
determines that the first user is a registered user of the digital
asset exchange.
[0394] In embodiments, the digital asset exchange is licensed by a
government regulatory authority.
[0395] In embodiments, the underlying digital asset is ether and
the blockchain is the Ethereum Blockchain.
[0396] In embodiments, the underlying digital asset is neo and the
blockchain is the Neo Blockchain.
[0397] In embodiments, the fixed predetermined ratio is one stable
value digital asset token is equal to one U.S. dollar.
[0398] In embodiments, the fixed predetermined ratio is one hundred
stable value digital asset tokens is equal to one U.S. dollar.
Increasing the Total Supply of Digital Asset Tokens
[0399] FIG. 18A is a schematic drawing of an exemplary system for
increasing the total supply of digital asset tokens on an
underlying blockchain in accordance with exemplary embodiments of
the present invention. The system shown in FIG. 18A may include an
administrator system 1801 which may communicate with a plurality of
end users, each of which may access the network 15 using one or
more corresponding user device 1805, . . . 1805X, a blockchain
1807, and one or more on-line keysets 1362, . . . 1362N.
[0400] In embodiments, network 15, may be a wide area network, a
local area network, a telephone network, dedicated access lines, a
proprietary network, a satellite network, a wireless network, a
mesh network, or through some other form of end-user to end-user
interconnection, which may transmit data and/or other information.
Any participants in a digital asset network may be connected
directly or indirectly, as through the data network 15, through
wired, wireless, or other connections. In embodiments, network 15
may be accessed using Transfer Control Protocol and Internet
Protocol ("TCP/IP") (e.g., any of the protocols used in each of the
TCP/IP layers), Hypertext Transfer Protocol ("HTTP"), WebRTC, SIP,
and wireless application protocol ("WAP"), are some of the various
types of protocols that may be used to facilitate communications
between administrator system 1801 and user devices 1805, . . .
1805X. In some embodiments, el administrator system 1801 and/or
user devices 1805, . . . 1805X may communicate with one another via
a web browser using HTTP. Various additional communication
protocols may be used to facilitate communications between
administrator system 1801 and/or user devices 1805, . . . 1805X,
including, but not limited to, Wi-Fi (e.g., 802.11 protocol),
Bluetooth, radio frequency systems (e.g., 900 MHz, 1.4 GHz, and 5.6
GHz communication systems), cellular networks (e.g., GSM, AMPS,
GPRS, CDMA, EV-DO, EDGE, 3GSM, DECT, IS 136/TDMA, iDen, LTE or any
other suitable cellular network protocol), infrared, BitTorrent,
FTP, RTP, RTSP, SSH, and/or VOIP.
[0401] As illustrated in FIG. 18A, the administrator system 1801
and/or user devices 1805, . . . 1805X may communicate with a
blockchain network to access and/or add blocks to blockchain 1807.
User devices 1805, . . . 1805X may for instance, may correspond to
a suitable electronic device, such as, desktop computers, mobile
computers (e.g., laptops, ultrabooks), mobile phones, smart phones,
tablets, personal display devices, large scale display devices
(e.g., billboards, street signs, etc.), personal digital assistants
("PDAs"), gaming consoles and/or devices, smart vehicles (e.g.,
cars, trucks, motorcycles, etc.), smart transportation devices
(e.g., boats, ships, trains, airplanes, etc.), and/or wearable
devices (e.g., watches, pins/broaches, headphones, etc.), to name a
few.
[0402] The blockchain 1807 may include one more contract addresses,
such as contract address for, e.g., a proxy smart contract 1310
(contract address 1), IMPL smart contract 1320 (contract address
2), PRINT LIMITER smart contract 1360 (contract address 3), STORE
smart contract 1330 (contract address 4), CUSTODIAN 1 smart
contract 1819 (contract address 5), CUSTODIAN 2 smart contract 1350
(contract address 6), CUSTODIAN 3 smart contract 1823 (contract
address 7), as illustrated in FIG. 18A. Each contract address may
include one or more contract addresses. Additionally, in
embodiments, one or more contract addresses shown in connection
with FIG. 18A may be associated with one or more contract
addresses. For example, in embodiments, contract address 1 may be
the same contract address as contract address 2. The blockchain
1807 may also include public addresses, such as off-line public
address 1 1817, off-line public address N 1817N, on-line public
address 1 1825, on-line public address N 1825N, user 1 public
address 1827, and User X public address 1827X, as illustrated in
FIG. 18A.
[0403] In embodiments, the blockchain 1807 may be a plurality of
geographically distributed computer systems in a peer-to-peer
network. Wireless communication may be provided using any of a
variety of communication protocols and/or wireless communication
networks, including e.g. GSM, GSM-R, UMTS, TD-LTE, LTE,
LTE-Advanced Pro, LTE Advanced, Gigabit LTE, CDMA, iDEN, MVNO,
MVNE, Satellite, TETRA, WiMAX, AMPS TDMA, Roaming SIM, DC-HSPA,
HSPA, HSPA+, HSDPA, G, 2G, 3.5G, 4G, 4.5G, 5G, 5.5G, 6G, 6.5G,
VoLTE, EDGE, GPRS, GNSS, EV-DO, 1xRTT, WCDMA, TDS-CDMA, CDMA2000,
CSFB, FDMA, OFDMA, PDMA, AMPS, EV-DO, DECT, IS-95, NMT, UMTS, MPLS,
MOCA, Broadband over Power Lines, NB-IoT, enhanced MTC (eMTC),
LTE-WLAN, ISDN, Microwave, Long Range Wifi, Point to Point Wifi,
EC-GSM-IoT, LTE-M, NB-IoT, Evolved Multicast Broadcast Multimedia
Service (eMBMS) and LTE-Broadcast (LTE-B), to name a few.
[0404] The system described in connection with FIG. 18A may include
one or more on-line keysets 1362, . . . 1362N. Each keyset includes
a private key and a corresponding public key (or public address on
the blockchain). For example, on-line keyset 1362 may be associated
with on-line public address 1 1825. Similarly, by way of example,
on-line keyset N 1362N may be associated with on-line public
address N 1825N. In embodiments, each private key will typically be
mathematically related to the corresponding public key, such as
used with cryptocurrency Security Standard. In embodiments, the one
or more on-line keysets 1362, . . . 1362N may be stored on
non-volatile computer readable memory of one or more computer
systems that are connected to the network, such as a first computer
system.
[0405] The system described in connection with FIG. 18A may also
include one or more off-line keyset 1803, . . . 1803N. Each keyset
includes a private key and a corresponding public key (or public
address on the blockchain). The offline keyset 1803 may be stored
in on non-volatile computer readable memory of one or more computer
systems that are physically separated from network 15, blockchain
1807, administrator system 1801, and the one or more computer
systems that store the on-line keysets, such as a second computer
system. In embodiments, the second computer system that is
physically separated and/or electronically may be a hardware
storage module (HSM 1900--as described more fully in connection
with FIG. 19B). The physical and/or electronic separation may serve
as an additional security measure(s), protecting the one or more
off-line keyset 1803, . . . 1803N from unauthorized access. In
embodiments, the one or more off-line keyset 1803, . . . 1803N may
be associated with address on the blockchain 1807. In embodiments,
off-line keyset 1 1803 may be associated with off-line public
address 1 1817. Off-line keyset 1803N may be associated with
off-line public address N 1817.
[0406] In embodiments, proxy smart contract 1310 may have a
contract address (e.g., contract address 1) associated therewith on
the blockchain 1807proxy smart contract 1310. Proxy smart contract
1310, as seen in FIG. 18B, by way of illustration and as discussed
in greater detail with respect to FIGS. 20A-20A-1, 20B-20C and
21A-21B, may include one or more modules of instructions 1310A-1
such as: (1) PROXY delegation instructions module 1829 (i.e. first
delegation instructions module) and (2) PROXY authorization
instructions module 1831 (i.e. first authorization instructions
module), to name a few.
[0407] In embodiments, PROXY delegation instructions module 1829
(i.e. first delegation instructions module) may include one or more
instructions to delegate received requests to other smart contracts
on the blockchain, such as, for example, IMPL smart contract 1320
(contract address 2), PRINT LIMITER smart contract 1360 (contract
address 3), STORE smart contract 1330 (contract address 4),
CUSTODIAN 1 smart contract 1819 (contract address 5), CUSTODIAN 2
smart contract 1350 (contract address 6), CUSTODIAN 3 smart
contract 1823 (contract address 7), to name a few. Additionally, in
embodiments, PROXY delegation instructions module 1829 (i.e. first
delegation instructions module) may include one or more
instructions to delegate received requests to public addresses such
as off-line public address 1 1817, off-line public address N 1817N,
on-line public address 1 1825, on-line public address N 1825N, user
1 public address 1827, and/or User X public address 1827X, to name
a few.
[0408] In embodiments, the first authorization instruction module
1831 may include instructions to authorize request received, the
requests, in embodiments, being transaction requests from
administrators, user public addresses, or other smart contracts, to
name a few.
[0409] In embodiments, PRINT LIMITER smart contract 1360 may have a
contract address (e.g. contract address 3) associated therewith on
the blockchain 1807. PRINT LIMITER smart contract 1360, as seen in
FIG. 18C, by way of illustration and as discussed in greater detail
with respect to FIGS. 20 and 21, may include one or more modules of
instructions 1360A-1 such as: (1) PRINT LIMITER token creation
instructions module 1833, (2), PRINT LIMITER first authorization
instructions module 1839 (i.e. second authorization instructions
module), (3) PRINT LIMITER second authorization instructions module
1841 (i.e. third authorization instructions module), (4) token
transfer instructions module 1843, (5) token destruction
instructions module 1845, and (6) token balance modification
instructions module 1847.
[0410] In embodiments, PRINT LIMITER token creation instructions
module 1833 may include one or more instructions that indicate
conditions under which tokens of a digital asset token are created.
In embodiments, the PRINT LIMITER token creation instructions
module 1833 may include instructions that limit the conditions
under which tokens may be created. For example, the PRINT LIMITER
token creation instructions module 1833 may include instructions
that limit the production of tokens to 1,000,000 tokens. In
embodiments, the instructions may also include a temporal
component. For example, the PRINT LIMITER token creation
instructions module 1833 may include instructions that only allow
1,000 tokens to be created within a 24 hour period. Or, as another
example, the PRINT LIMITER token creation instructions module 1833
may include instructions that only allow tokens to be created
during business hours. In embodiments, the PRINT LIMITER may also
include authorization instructions related to the first key
pair.
[0411] In embodiments, custodian instructions module 1835 may
include one or more instructions that limit the PRINT LIMITER smart
contract 1360A authority. For example, if a request is received by
the PRINT LIMITER smart contract 1360 to create digital asset
tokens beyond a pre-approved token supply limit, the custodian
instructions module 1835 may require authorization from a print
limiter custodian (i.e. CUSTODIAN 2 smart contract 1350 (contract
address 6)).
[0412] In embodiments, the second authorization instruction module
1839 and the PRINT LIMITER second authorization instructions module
1841 (i.e. third authorization instructions module) may each
include instructions to authorize request received, the requests,
in embodiments, being transaction requests from administrators,
user public addresses, or other smart contracts, to name a few.
Second authorization instruction module 1839 may include
instructions for the first designated key pair (on-line keyset 1
1362, . . . 1362N), with respect to token creation of the digital
asset token. In embodiments, the second authorization instructions
with respect to token creation may be below a first threshold over
a first period of time. PRINT LIMITER second authorization
instructions module 1841 (i.e. third authorization instructions
module) may include instructions for the second designated key pair
(i.e. off-line keyset 1803, . . . 1803N) with respect to token
creation of the digital asset token. In embodiments, PRINT LIMITER
first authorization instructions module 1839 and PRINT LIMITER
second authorization instructions module 1841 may be the same
module.
[0413] In embodiments, the PRINT LIMITER Third Authorization
Instructions Module 1835 may include instructions to modify the
token supply. For example, the PRINT LIMITER Third Authorization
Instructions Module 1835 may include instructions that, when called
to execute, may create and/or burn tokens of the digital asset
token. In embodiments, instructions that modify the token supply
may cause the STORE Smart Contract 1330 to alter an electronic
ledger that tracks the token supply.
[0414] In embodiments, the token transfer instructions module 1843,
in embodiments, may include instructions to transfer digital asset
tokens. In embodiments, the transfer may be from one public address
to another public address. For example, a transfer of tokens may be
from User 1 public address 1827 to User X public address 1827X. In
embodiments, such transfer instructions may include rules by which
certain transfer are allowed or blocked and may specify one or more
key pair or contract addresses that may be authorized to perform
one or more types of transfer operations. A more detailed
description of the transfer of digital asset tokens is located in
connection with the description of FIG. 19D, the same description
applying herein.
[0415] In embodiments, the token destruction instructions module
1845 may include instructions on when, and with whose authority,
security tokens associated with one or more specified addresses
shall be destroyed or "burned", and thus removed from the security
token supply. A more detailed description of token destruction is
described in connection with FIG. 19E, the same description
applying herein
[0416] In embodiments, token balance modification instructions
module 1847 may include instructions that may alter, edit, and/or
update a transaction ledger in accordance with token creation,
token transfer, and/or token destruction instructions (or modules),
to name a few.
[0417] In embodiments, CUSTODIAN 2 smart contract may have a
contract address (e.g. contract address 6) associated therewith on
the blockchain 1807. CUSTODIAN 2 smart contract 1350, as seen in
FIG. 18D, by way of illustration and as discussed in greater detail
with respect to FIGS. 20 and 21, may include one or more modules of
instructions 1350A-1 such as: (1) CUSTODIAN 2 first authorization
instructions module 1849 (i.e. fourth authorization instructions
module) and (2) CUSTODIAN 2 second authorization instructions
module 1851 (i.e. fifth authorization instructions module). In
embodiments, CUSTODIAN 2 first authorization instructions module
1849 and CUSTODIAN 2 second authorization instructions module 1851
may be the same module.
[0418] In embodiments, the CUSTODIAN 2 first authorization
instructions module 1849 (i.e. fourth authorization instructions
module) and the CUSTODIAN 2 second authorization instructions
module 1851 (i.e. fifth authorization instructions module) may each
include instructions to authorize request received, the requests,
in embodiments, being transaction requests from administrators,
user public addresses, or other smart contracts, to name a few
CUSTODIAN 2 first authorization instructions module 1849 (i.e.
fourth authorization instructions module) may include instructions
for the off-line keyset 1803, . . . 1803N to authorize the issuance
of instructions to the PRINT LIMITER smart contract 1360 with
respect to token creation, above a first threshold during a first
period of time. CUSTODIAN 2 second authorization instructions
module 1851 (i.e. fifth authorization instructions module) may
include instructions to raise a ceiling of token creation. A more
detailed description of raising the ceiling of token creation is
located below in the descriptions in connection with FIGS. 19A-B
and 20A.
[0419] In embodiments, STORE smart contract 1330 may have a
contract address (e.g. contract address 4) associated therewith on
the blockchain 1807. STORE smart contract 1330, as seen in FIG.
18E, by way of illustration as discussed in greater detail with
respect to FIGS. 20 and 21, may include one or more modules of
instructions 1330A-1 such as: (1) storage instructions module 1853
and (2) STORE authorization instructions module 1855 (i.e. sixth
authorization instructions module).
[0420] In embodiments, storage instructions module 1853, may
include instructions to store any alterations, edits, or updates to
a transaction ledger in accordance with token creation, token
transfer, and/or token destruction. In embodiments, the storage
instructions module 1853 may be called through a transaction
request received from one or more smart contracts. For example, as
shown in FIG. 19C, the IMPL smart contract 1320 may call the store
smart contract 1330, authorizing the change of a transaction ledger
to include an earlier transaction. In embodiments, the transaction
ledger may be updated immediately after each token creation,
transfer, and/or destruction. In embodiments, the storage
instructions module 1853 may execute instructions to update a
transaction ledger at certain times and/or dates. For example, the
storage instructions module 1853 may only update a transaction
ledger at the close of business. As another example, the storage
instructions module 1853 may only update a transaction ledger at
every second, minute, hour, or multiple hours, to name a few. A
more detailed description of instructions related to the storage
instructions module 1853 is located in connection with the
descriptions of FIGS. 19-21, the same descriptions applying
herein.
[0421] In embodiments, the STORE authorization instructions module
1855 may include instructions to authorize request received, the
requests, in embodiments, being transaction requests from
administrators, user public addresses, or other smart contracts, to
name a few.
[0422] In embodiments, IMPL smart contract 1320 may have a contract
address (e.g. contract address 2) associated therewith on the
blockchain 1807. The IMPL smart contract 1320, as seen in FIG. 18F,
by way of illustration and discussed in greater detail with respect
to FIGS. 19-21, may include one or more modules of instructions
1320A-1 such as: (1) Generate Hash Instructions Module 1857; (2)
IMPL Authorization Instructions Module 1859; (3) IMPL Token
Transfer Instructions Module 1861; (4) IMPL Token Balance
Modification Instructions Module 1863; (5) IMPL delegation
instructions module 1837 (i.e. second delegation instructions
module); and (6) IMPL Token Creation Instructions Module 1865.
[0423] In embodiments, the generate hash instructions module 1857
may include instructions to generate a unique hash. A unique hash
may be generated by the generate hash instructions module 1857 by
applying a hash algorithm. Examples of hash algorithms include MD
5, SHA 1, SHA 256, RIPEMD, and Keccak-256, to name a few. Hash
algorithms take an input of any length and create an output of
fixed length, allowing the trade instructions to be detectable and
usable by administrators and users on the underlying
blockchain.
[0424] In embodiments, the IMPL authorization instructions module
1859 may include instructions to authorize request received, the
requests, in embodiments, being transaction requests from
administrators, user public addresses, or other smart contracts, to
name a few. In embodiments, the requests may include requests to
generate digital asset tokens from administrators, user public
addresses, and/or other smart contracts, to name a few.
[0425] In embodiments, the IMPL token transfer instructions module
1861 may include instructions to transfer digital asset tokens. In
embodiments, the transfer may be from one public address to another
public address. For example, a transfer of tokens may be from User
1 public address 1827 to User X public address 1827X. In
embodiments, such transfer instructions may include rules by which
certain transfer are allowed or blocked and may specify one or more
key pair or contract addresses that may be authorized to perform
one or more types of transfer operations. In embodiments, the IMPL
token transfer instructions module 1861 may be similar to the token
transfer instructions module 1843, described in connection with
FIG. 18C. In embodiments, a transfer of digital asset tokens using
the blockchain 1807 may be accomplished using either the IMPL token
transfer instructions module 1861 or the token transfer
instructions module 1843. In embodiments, a transfer of digital
asset tokens using the blockchain 1807 may be accomplished using
both the IMPL token transfer instructions module 1861 and the token
transfer instructions module 1843. In embodiments, the IMPL smart
contract 1320 and the PRINT LIMITER smart contract 1360 may be the
same smart contract. A more detailed description of the transfer of
digital asset tokens is located in connection with the description
of FIG. 19D, the same description applying herein.
[0426] In embodiments, IMPL token balance modification instructions
module 1863 may include instructions that may alter, edit, and/or
update a transaction ledger in accordance with token creation,
token transfer, and/or token destruction instructions (or modules),
to name a few. In embodiments, the IMPL token balance modification
instructions module 1863 may be similar to the token balance
modification module 1847 described in connection with FIG. 18C. In
embodiments, a token balance modification may be accomplished using
either the token balance modification module 1847 or the IMPL token
balance modification module 1863. In embodiments, a token balance
modification may be accomplished using both the token balance
modification module 1847 and the IMPL token balance modification
module 1863. A more detailed description of a token balance
modification is located in connection with the description of FIGS.
19-21, the same descriptions applying herein.
[0427] In embodiments, IMPL delegation instructions module 1837
(i.e. second delegation instructions module) may include one or
more instructions to delegate received requests to other smart
contracts, such as, for example, contract address 1 (proxy smart
contract) 1809, PRINT LIMITER smart contract 1360 (contract address
2), STORE smart contract 1330 (contract address 4), CUSTODIAN 1
smart contract 1819 (contract address 5), CUSTODIAN 2 smart
contract 1350 (contract address 6), CUSTODIAN 3 smart contract 1823
(contract address 7), off-line public address 1 1817, off-line
public address N 1817N, on-line public address 1 1825, on-line
public address N 1825N, user 1 public address 1827, and/or User X
public address 1827X. PRINT LIMITER delegation instructions module
1837 (i.e. second delegation instructions module) may include
instructions for delegating to one or more designated store
contract addresses data storage operations or other functions for
the digital asset token as authorized by the first designated
custodian contract address.
[0428] In embodiments, the IMPL token creation module 1865 may
include one or more instructions to create digital asset tokens,
and thus add to the token supply. Such instructions may specify one
or more authorized key pairs or contract addresses that may be
authorized to request creation of security tokens under specified
conditions (such as one or more on-line keysets 1362, . . . 1362N).
In embodiments, the token creation instructions module 1833 may
include instructions related to increasing the token supply. In
embodiments, the token creation instructions module 1865 may
include instructions on how to create new digital asset tokens
within pre-approved token supply limits and how to assign newly
created or "minted" tokens to specific designated public addresses
or contract addresses on the underlying blockchain. In embodiments,
the IMPL token creation module 1865 may cause the IMPL Smart
Contract 1320 to communicate with STORE Smart contract 1330, the
IMPL Smart Contract 1320 sending a transaction request to the Store
Smart Contract 1330, causing the Store Smart Contract 1330 to alter
a ledger, or otherwise record an increase or decrease in the token
supply of a digital asset token.
[0429] Referring to FIG. 20A, In step S2002, a first designated key
pair (on-line keyset 1 1362) including a first public key of an
underlying digital asset and a corresponding first designated
private key is provided. In embodiments, the underlying digital
asset is maintained on a distributed public transaction ledger
maintained by a plurality of geographically distributed computer
systems in a peer-to-peer network in the form of the blockchain
1807. In embodiments, the first designated private key is stored on
a first computer system which is connected to the distributed
public transaction ledger 15). In embodiments, the first designated
key pair may be multiple on-line keys with multiple electronic
signatures.
[0430] In step S2004, a second designated key pair including a
second designated public key (off-line keyset 1803) of the
underlying digital asset and a corresponding second designated
private key is provided. In embodiments, the second designated
private key is stored on a second computer system which is
physically separated from the first computer system and is not
operatively or physically connected to the distributed public
transaction ledger or the internet (network 15). In embodiments,
the second computer system may be the hardware storage module 1900.
In embodiments, the second designated key pair may be multiple
on-line keys with multiple electronic signatures.
[0431] In step S2006, first smart contract instructions for a
digital asset token associated with a first contract address
associated with the blockchain associated with the underlying
digital asset are provided. In embodiments, the first contract
address is contract address 1 (proxy smart contract) 1809 and first
smart contract instructions of step S2006 are the proxy contract
instructions 1310A-1, both described in connection with FIG. 18B.
The first smart contract instructions may be saved in the
blockchain 1807 and include first delegation instructions and first
authorization instructions. The first delegation instructions may
delegate one or more first functions associated with the digital
asset token to one or more delegated contract addresses associated
with the underlying digital asset, the delegated contract
addresses, in embodiments, being different than the first contract
address. In embodiments, the first delegation instructions may be
located with first delegation instruction module 1829 described in
connection with FIG. 18B. In embodiments, the first smart contract
instructions, may also include first authorization instructions for
the second designated key pair. In embodiments, the first
authorization instructions may be located with first authorization
instructions module 1830 described in connection with FIG. 18B.
[0432] In step S2008, second smart contract instructions for the
digital asset token associated with a second contract address
associated with the blockchain associated with the underlying
digital asset may be provided. In embodiments, the second smart
contract address is at contract address 3 (print limiter smart
contact) 1813 and the second smart contract instructions are the
print limiter contract instructions 1360A-1, both described in
connection with FIG. 18C. In embodiments, the second contract
address is different from the first contract address. In
embodiments, the second smart contract instructions may be saved in
the blockchain 1807 and, as described in connection with the print
limiter contract instructions 1360A-1 of FIG. 18C (the descriptions
of which applying herein), include: (1) token creation
instructions; (2) custodian instructions; (3) second delegation
instructions; (4) second authorization instructions; and (5) third
authorization instructions. In embodiments, as described above in
connection with print limiter contract instructions 1360A-1 of FIG.
18C (the description of which applying herein), the second smart
contract instructions may also include: (6) token transfer
instructions of token transfer instructions module 1843 to transfer
tokens of the digital asset token from a first designated address
to a second designated address.
[0433] In embodiments, as described above in connection with print
limiter contract instructions 1360A-1 of FIG. 18C (the description
of which applying herein), the second smart contract instructions
may also include: (7) token destruction instructions of token
destruction instructions module 1845 to destroy one or more tokens
of the digital asset token. Token destruction instructions, in
embodiments, may not be limited to print limiter contract
instructions 1360A-1. In embodiments, additional smart contracts
may also destroy tokens, such as IMPL smart contract 1320 (contract
address 2), CUSTODIAN 1 smart contract 1819 (contract address 5),
CUSTODIAN 2 smart contract 1350 (contract address 6), and/or
CUSTODIAN 3 smart contract 1823 (contract address 7), to name a
few.
[0434] In embodiments, as described above in connection with print
limiter contract instructions 1360A-1 of FIG. 18C (the description
of which applying herein), the second smart contract instructions
may also include: (8) token balance modification instructions of
token balance modification instructions module 1847 to modify a
total number of tokens of the digital asset token assigned to a
third designated address.
[0435] In step S2010, third smart contract instructions for the
digital asset token associated with a third contract address
associated with the blockchain associated with the underlying
digital asset are provided. In embodiments, the third smart
contract address is CUSTODIAN 2 smart contract 1350 (contract
address 6) and the second smart contract instructions are the
custodian 2 contract instructions 1350A-1, both described in
connection with FIG. 18D. The third smart contract instructions may
be saved in the blockchain 1807 and, as described in connection
with the custodian 2 smart contract instructions 1350A-1 of FIG.
18D (the descriptions of which applying herein), include: (1)
fourth authorization instructions and (2) fifth authorization
instructions. The fourth authorization instructions of CUSTODIAN 2
first authorization instructions module 1849 (i.e. fourth
authorization instructions module) may include instructions for the
second designated key pair to authorize the issuance of
instructions to the second smart contract instructions with respect
to token creation. In embodiments, the authorization instructions
with respect to token creation may be above the first threshold
during the first time period.
[0436] In embodiments, a token creation request may exceed a
ceiling (i.e. a request for 150 tokens when the ceiling is 100
tokens), CUSTODIAN 2 smart contract 1350 may authorize an increase
in the ceiling. This authorization may be fifth authorization
instructions of the CUSTODIAN 2 second authorization instructions
module 1851 (i.e. fifth authorization instructions module), and may
include instructions for the second designated key pair (off-line
keyset 1803, . . . 1803N) to authorize the issuance of instructions
to the first smart contract instructions to change the one or more
designated contract address from the second contract address to a
different designated contract address. In embodiments, a ceiling is
raised by creating a second print limiter smart contract on the
blockchain 1807 with a higher ceiling. Once the second print
limiter smart contract is created, the request for token creation
can be routed to the second print limiter smart contract.
[0437] A more detailed description of the process of raising the
token creation ceiling is located in connection with FIGS. 19A-B.
FIGS. 19A-B are schematic drawings of an exemplary process for
increasing the ceiling of a print limiter in accordance with
exemplary embodiments of the present invention. The exemplary
process starts with administrator system 1801 sending a first
transaction request 1901 from on-line public address 1 1825 to
PRINT LIMITER smart contract 1360 (contract address 3). In
embodiments, the transaction request 1901 includes a request to
raise the ceiling by amount 1. In embodiments, the first
transaction request 1901 is signed by on-line private key 1. In
embodiments, on-line private key 1 is mathematically related to
on-line public address 1 1825.
[0438] In response to receiving the first transaction request, the
print limiter 1813 executes the first transaction request 1903 and
returns a unique lock identifier (LockId1) to IMPL smart contract
1320 (contract address 2).
[0439] Next, referring to FIG. 19B, a second transaction request
1905 may be sent from the on-line public address 1825 to contract
address 6 (custodian (print limiter)) 1821. In embodiments, the
second transaction request 1905 includes a request to unlock
ceiling raise by amount 1, the request being confirmed with the
lockID received in step 1903. In embodiments, the second
transaction request 1905 is signed by on-line private key 1.
[0440] In response to receiving the second transaction request,
custodian 1821 executes the second transaction request 1907 and
returns a unique hash (reqMessageHash1). The unique hash may be
generated by applying a hash algorithm. Examples of hash algorithms
include MD 5, SHA 1, SHA 256, RIPEMD, and Keccak-256 to name a few.
Hash algorithms take an input of any length and create an output of
fixed length, allowing the trade instructions to be detectable and
usable by administrators and users on the underlying blockchain.
However, applying a hash algorithm is not always necessary if trade
instructions are published ahead of time.
[0441] In response to the returned unique hash, a third transaction
request is generated 1909. The third transaction request may
include a request that the reqMessageHash1 to be signed by HSM 1900
offline.
[0442] The third request then may be sent 1911 to HSM 1900 and
signed using offline private keyset 1803. The signed request may be
returned to administrator system 1801.
[0443] After returning the signed transaction request, the third
transaction request is may be sent 1913 from the on-line public
address 1825 to contract address 6 (custodian (print limiter))
1821. The third transaction request may include a fourth request to
complete the unlock with requestMessageHash1 with the HSM
signature. In embodiments, the fourth request is signed by on-line
private key 1.
[0444] After receiving the fourth request, custodian 1821 may
execute the request to validate the unlock and return call to
contract address 3 (print limiter) 1813 to raise the ceiling, which
returns call to contract address 4 (store) 1815 to raise ceiling
which updates ceiling.
[0445] The process of FIG. 20A may continue with step S2012 of FIG.
20A-1. In step S2012, fourth smart contract instructions for the
digital asset token associated with a fourth contract address
associated with the blockchain associated with the underlying
digital asset are provided. In embodiments, the fourth contract
address is STORE smart contract 1330 (contract address 4) and
fourth smart contract instructions of step S2012 are the store
contract instructions 1330A-1, both described in connection with
FIG. 18E. The fourth smart contract instructions may include: (1)
storage instructions and (2) sixth authorization instructions. In
embodiments, storage instructions of storage instructions module
1853 may include instructions for transaction data related to the
digital asset token to be stored. The transaction data may include
(for all issued tokens of the digital asset token): (1) public
address information associated with the underlying digital asset;
and (2) corresponding token balance information associated with
said public address information. In embodiments, sixth
authorization instructions of authorization instructions module
1855 may include instructions for modifying the transaction data in
response to request from the second contract address (print limiter
1813).
[0446] The process may continue with step S2013. At step S2013,
fifth smart contract instructions for the digital asset token for
the digital asset token associated with the blockchain associated
with the underlying digital asset are provided. In embodiments, the
fifth contract address is the IMPL smart contract 1320 (contract
address 2) and the fifth smart contract instructions of step S2013
are the IMPL Contract instructions 1320A-1, both described in
connection with FIG. 18F. In embodiments, the fifth smart contract
instructions may be saved in the blockchain for the underlying
digital assets and may include (1) token creation instructions to
create tokens of the digital asset tokens under conditions set
forth by the print limiter token creation instructions; and (2)
second delegation instructions for delegating to another contract
address, data storage operations. In embodiments, instructions from
the PRINT LIMITER Token Creation Instructions Module 1833 may set
conditions for the token creation instructions included with the
fourth smart contract instructions (i.e. instructions included in
the IMPL Token Creation Instructions Module 1865).
[0447] The process described in FIG. 20A-1 may continue with step
S2014. At step S2014, a digital asset token issuer system increases
the total supply of the digital asset token from a first amount to
a second amount. Step S2014 is described in more detail in
connection with FIGS. 20B-C. Increasing the total supply of the
digital asset token may being with step S2018. At step S2018, a
first transaction request may be generated by the digital asset
token issuer system. The generated transaction request may include
a first message including a first request to increase the total
supply of the digital asset token to a second amount of digital
asset tokens. The first transaction request being from the on-line
public key address 1825 to the fifth contract address (IMPL 1320).
In embodiments, the first transaction request may be signed by the
first on-line private key.
[0448] In step S2020 the first transaction request is sent by the
digital asset token issuer system, from the on-line public key
address 1825 to the fifth contract address (IMPL 1320).
[0449] Next, In step S2021, the first transaction request is sent
by the digital asset token issuer system via the underlying
blockchain from the fifth contract address (IMPL 1320) to the
second contract address (PRINT LIMITER 1360). In embodiments, the
second contract address (PRINT LIMITER 1360) executes, via the
blockchain 1807, the first transaction request to return a first
unique lock identifier associated with the first transaction
request. In embodiments, the first transaction request may include
first transaction fee information for miners in the blockchain
network to process the first transaction request.
[0450] Next, In step S2022, the first unique lock identifier may be
obtained by the digital asset token issuer system, based on
reference to the blockchain 1807.
[0451] In step S2024, a second transaction request may be generated
by the digital asset token issuer system. The generated transaction
request may include a second message including a second request to
unlock the total supply of the digital asset token in accordance
with the first request including the first unique lock identifier.
The second transaction request being from the on-line public key
address 1825 to the third contract address (custodian (print
limiter) 1350). In embodiments, the second transaction request may
be signed by the first on-line private key.
[0452] In step S2026 the second transaction request is sent by the
digital asset token issuer system, from the on-line public key
address 1825 to the third contract address (custodian (print
limiter) 1350). In embodiments, the third contract address
(custodian (print limiter) 1350) executes, via the blockchain 1807,
the first transaction request to return a first unique lock
identifier associated with the second transaction request to return
a first unique request hash associated with the second transaction
request. In embodiments, the first transaction request may include
second transaction fee information for miners in the blockchain
network to process the second transaction request.
[0453] Next, In step S2028, the first unique request hash is
obtained, by the digital asset token issuer system, based on
reference to the blockchain 1807.
[0454] The process described in FIG. 20B may continue with step
S2030 of FIG. 20C. At step S2030, a third transaction request is
generated by the digital asset token issuer system. The third
transaction request may be digitally signed by at least the second
designated private key (off-line keyset 1803) including the first
unique request hash.
[0455] Next, at step S2032, the third transaction request is
transferred from the digital asset token issuer system to a first
portable memory device. A portable memory device may, in
embodiments, be a flash drive, USB drives, external hard drives,
and/or portable CD/DVD-ROM drives, to name a few.
[0456] At step 2034, the third transaction request is transferred
from the first portable memory device to the second computer
system. Next, at a step S2036, the third transaction request is
digitally signed using the second designated private key (off-line
keyset 1803) to generate a third digitally signed transaction
request.
[0457] The process of FIGS. 20B and 20C may continue with step
S2038. At step S2038, the third digitally signed transaction
request is sent from a second portable memory device using the
digital asset token issuer system to the third contract address
(custodian (print limiter) 1350).
[0458] In embodiments, the first portable memory device is the
second portable memory device. In embodiments, the first portable
memory device is not the second portable memory device. In
embodiments, the third digitally signed transaction request is
returned to the STORE smart contract 1330. Once returned to the
STORE smart contract 1330, the third digitally signed transaction
request is returned to the print limiter 1813.
[0459] Referring back to FIG. 20A-1, the process may continue with
step S2016. At step S2016, the digital asset token issuer system
confirms that the total supply of digital asset tokens is set to
the second amount. In embodiments, the third smart contract
(custodian (print limiter) 1350) executes, via the blockchain
network, the third digitally signed transaction request to validate
the second request to unlock based on the third digitally signed
transaction request and the first unique request hash and executes
a first call to the second contract address (PRINT LIMITER 1360),
to increase the total supply of the digital asset token to the
second amount of digital asset tokens. In embodiments, the second
contract address (PRINT LIMITER 1360) may return the first call to
the fifth contract address (IMPL 1320). In embodiments, the fifth
smart contract (IMPL 1320) executes, via the blockchain network, a
second call to the fourth smart contract address (STORE 1330) to
set the total supply of the digital asset tokens to the second
amount of digital asset tokens. In embodiments, the fourth smart
contract (STORE 1330) executes, via the blockchain, the second call
to set the total supply of the digital asset tokens to the second
amount of digital asset tokens.
[0460] In embodiments, the steps of FIGS. 20A and 20B may be
rearranged and/or omitted.
[0461] Merely for the purposes of description, the following
example is provided.
EXAMPLE 1
Increase the Supply Ceiling by 100 Million Cents
TABLE-US-00006 [0462] Tx 1. TO = address of PrintLimiter DATA =
'requestCeilingRaise(100,000,000)' (Tx would be signed by
Adminstrator's 'primary' key, although there are no restrictions
onwho can call this function.) Execution produces a unique lock
identifier, say 'lockId1'.
TABLE-US-00007 Tx 2. TO = address of (Print)Custodian (instance of
the Custodian contract, with cold tier keys, intended to be the
offline custodian of printing operations) DATA =
'requestUnlock(lockId1, address of PrintLimiter, selector for
functionconfirmCeilingRaise, ...and a detail I'm going to omit...)'
(Tx would be signed by Adminstrator's `primary` key, although there
are no restrictions on who can call this function. If it's a not
the primary key there is an anti-spam mechanism.) Execution
produces a unique request hash, say 'reqMsgHash1. 2 of the offline
keys set up with (Print)Custodian sign 'reqMsgHash1'; we'll name
the signatures 'sig1_a' and 'sig1_b' .
TABLE-US-00008 Tx 3. TO = address of (Print)Custodian DATA =
'completeUnlock(requestMsgHash1, sig1_a, sig1_b)' (Tx would be
signed by Adminstrator's `primary` key, although there are no
restrictions on who can call this function.) Execution validates
the signatures (and enforces other details around time locks and
revocation). Next, it executes a call to PrintLimiter and its
confirmCeilingRaise (NOTE that those two detailed were fixed in Tx2
as parameters to the call to requestUnlock). CALL '(address of
PrintLimiter).confirmCeilingRaise(lockId1)' Execution continues in
PrintLimiter in the function 'confirmCeilingRaise'. Storage for the
contract is updated: STORE supply ceiling = current supply ceiling
+ 100,000,000
[0463] FIG. 21A is a flowchart of an exemplary process of
increasing the total supply of digital asset tokens in accordance
with exemplary embodiments of the present invention. The process of
FIG. 21A may begin with step S2102. In step S2102, a first
designated key pair (on-line keyset 1 1362) including a first
public key of an underlying digital asset and a corresponding first
designated private key is provided. In embodiments, the underlying
digital asset is maintained on a distributed public transaction
ledger maintained by a plurality of geographically distributed
computer systems in a peer-to-peer network in the form of the
blockchain 1807. In embodiments, the first designated private key
is stored on a first computer system which is connected to the
distributed public transaction ledger through the internet (network
15). In embodiments, the first designated key pair may be multiple
on-line keys with multiple electronic signatures.
[0464] In step S2104, a second designated key pair including a
second designated public key (off-line keyset 1803) of the
underlying digital asset and a corresponding second designated
private key is provided. In embodiments, the second designated
private key is stored on a second computer system which is
physically separated from the first computer system and is not
operatively or physically connected to the distributed public
transaction ledger or the internet (network 15). In embodiments,
the second computer system may be the hardware storage module 1900.
In embodiments, the second designated key pair may be multiple
on-line keys with multiple electronic signatures.
[0465] In step S2106, first smart contract instructions for a
digital asset token associated with a first contract address
associated with the blockchain associated with the underlying
digital asset are provided. In embodiments, the first contract
address is contract address 1 (proxy smart contract) 1809 and first
smart contract instructions of step S2106 are the proxy contract
instructions 1310A-1, both described in connection with FIG. 18B.
The first smart contract instructions, may, be saved in the
blockchain 1807 and include first delegation instructions and first
authorization instructions. The first delegation instructions may
delegate one or more first functions associated with the digital
asset token to one or more delegated contract addresses associated
with the underlying digital asset, the delegated contract
addresses, in embodiments, being different than the first contract
address. The first delegation instructions may be located with
first delectation instructions module 1829 described in connection
with FIG. 18B. The first smart contract instructions, may also
include first authorization instructions for the second designated
key pair. The first authorization instructions may be located with
first authorization instructions module 1830 described in
connection with FIG. 18B.
[0466] In step S2108, a second contract instructions for the
digital asset token associated with a second contract address
associated with the blockchain associated with the underlying
digital asset is provided. In embodiments, the second smart
contract address is contract address 3 (print limiter smart
contact) 1813 and the second smart contract instructions are the
print limiter contract instructions 1360A-1, both described in
connection with FIG. 18C. In embodiments, the second contract
address is not the first contract address. The second smart
contract instructions may be saved in the blockchain 1807 and, as
described in connection with the print limiter contract
instructions 1360A-1 of FIG. 18C (the descriptions of which
applying herein), include: (1) token creation instructions; (2)
custodian instructions; (3) second delegation instructions; (4)
second authorization instructions; and (5) third authorization
instructions. In embodiments, as described above in connection with
print limiter contract instructions 1360A-1 of FIG. 18C (the
description of which applying herein), the second smart contract
instructions may also include: (6) token transfer instructions of
token transfer instructions module 1843 to transfer tokens of the
digital asset token from a first designated address to a second
designated address.
[0467] In embodiments, as described above in connection with print
limiter contract instructions 1360A-1 of FIG. 18C (the description
of which applying herein), the second smart contract instructions
may also include: (7) token destruction instructions of token
destruction instructions module 1845 to destroy one or more tokens
of the digital asset token. Token destruction instructions, in
embodiments, may not be limited to print limiter contract
instructions 1360A-1. In embodiments, additional smart contracts
may also destroy tokens, such as IMPL smart contract 1320 (contract
address 2), CUSTODIAN 1 smart contract 1819 (contract address 5),
CUSTODIAN 2 smart contract 1350 (contract address 6), and/or
CUSTODIAN 3 smart contract 1823 (contract address 7), to name a
few.
[0468] In embodiments, as described above in connection with print
limiter contract instructions 1360A-1 of FIG. 18C (the description
of which applying herein), the second smart contract instructions
may also include: (8) token balance modification instructions of
token balance modification instructions module 1847 to modify a
total number of tokens of the digital asset token assigned to a
third designated address.
[0469] In step S2110, third smart contract instructions for the
digital asset token associated with a third contract address
associated with the blockchain associated with the underlying
digital asset are provided. In embodiments, the third smart
contract address is CUSTODIAN 2 smart contract 1350 (contract
address 6) and the second smart contract instructions are the
custodian 2 contract instructions 1350A-1, both described in
connection with FIG. 18D. The third smart contract instructions may
be saved in the blockchain 1807 and, as described in connection
with the custodian 2 smart contract instructions 1350A-1 of FIG.
18D (the descriptions of which applying herein), include: (1)
fourth authorization instructions and (2) fifth authorization
instructions. The fourth authorization instructions of CUSTODIAN 2
first authorization instructions module 1849 (i.e. fourth
authorization instructions module) may include instructions for the
second designated key pair to authorize the issuance of
instructions to the second smart contract instructions with respect
to token creation. In embodiments, the authorization instructions
with respect to token creation may be above the first threshold
during the first time period.
[0470] In embodiments, a token creation request may exceed a
ceiling (i.e. a request for 150 tokens when the ceiling is 100
tokens), CUSTODIAN 2 smart contract 1350 may authorize an increase
in the ceiling. This authorization may be fifth authorization
instructions of the CUSTODIAN 2 second authorization instructions
module 1851 (i.e. fifth authorization instructions module), and may
include instructions for the second designated key pair (off-line
keyset 1803, . . . 1803N) to authorize the issuance of instructions
to the first smart contract instructions to change the one or more
designated contract address from the second contract address to a
different designated contract address. In embodiments, a ceiling is
raised by creating a second print limiter smart contract on the
blockchain 1807 with a higher ceiling. Once the second print
limiter smart contract is created, the request for token creation
can be routed to the second print limiter smart contract.
[0471] A more detailed description of the process of raising the
token creation ceiling is located above in connection with FIGS.
19A-B, the description of which applying herein.
[0472] The process of FIG. 21A may continue with step S2112. At
step 2112, fourth smart contract instructions are provided for the
digital asset token associated with a fourth contract address
associated with the blockchain associated with the underlying
digital asset. In embodiments, the fourth contract address is STORE
smart contract 1330 (contract address 4) and fourth smart contract
instructions of step S2112 are the store contract instructions
1330A-1, both described in connection with FIG. 18E. The fourth
smart contract instructions may include: (1) storage instructions
and (2) sixth authorization instructions. In embodiments, storage
instructions of storage instructions module 1853 may include
instructions for transaction data related to the digital asset
token to be stored. The transaction data may include (for all
issued tokens of the digital asset token): (1) public address
information associated with the underlying digital asset; and (2)
corresponding token balance information associated with said public
address information. In embodiments, sixth authorization
instructions of authorization instructions module 1855 may include
instructions for modifying the transaction data in response to
request from the second contract address (print limiter 1813).
[0473] At a step S2114, fifth smart contract instructions are
provided for the digital asset token associated with a fifth
contract address associated with the blockchain associated with the
underlying digital asset. In embodiments, the fifth smart contract
address is IMPL smart contract 1320 (contract address 2) and the
fifth smart contract instructions are impl contract instructions
1320A-1.
[0474] The process of FIG. 21A may continue with step S2116 of FIG.
21B. At step S2116, a request to generate and assign a first amount
of digital token to a first designated public address is received
by the digital asset token issuer system. In embodiments, the first
designated public address may be User 1 public address 1827, User 1
public address 1827 being associated with User 1 Device 1805. In
embodiments, a validation request may be sent to the on-line key
public address 1 1825. The validation request may determine whether
the first amount of digital token is available to be generated and
assigned. In embodiments, the digital asset token issuer system may
determine whether the on-line key has the authority to process the
request to generate and assign the first amount of digital token.
This determination may be made based on a variety of factors,
including whether the first amount of digital token is actually
available and/or the ceiling of digital asset tokens for a specific
time period, to name a few.
[0475] At step, S2118, the digital asset token issuer system
generates the first amount of digital asset token and assigns the
first amount of digital asset tokens to the first designated public
address. In embodiments, step S2118 may include the digital asset
token issuer system generating a first transaction request. The
first transaction request, in embodiments, may be address from the
online public key address (On-line public address 1 1825) to the
fifth contract address (IMPL Smart Contract (Contract Address 2)
1320). The first transaction request may include a first message
including a first request to generate the first amount of digital
asset token and assign said first amount of digital asset token to
the first designated public address. In embodiments, the first
transaction request is digitally signed by the first on-line
private key (on-line keyset 1362). After the transaction request is
generated, the first transaction request may be sent from the
online public key address (On-line public address 1 1825) to the
fifth contract address (IMPL smart contract 1320 (contract address
2)). In embodiments, the first transaction request includes first
transaction fee information for miners in the blockchain network to
process the first transaction request.
[0476] After the first transaction request is received by the fifth
contract address, in embodiments, the fifth smart contract (IMPL
1320) may execute, via the blockchain 1807, the first transaction
request to validate the first request and the authority of the
first on-line private key (on-line keyset 1 1362) to call the
second smart contract (print limiter 1813) to execute the first
transaction request. The second smart contract (print limiter 1360)
may also send a first call request to the fifth contract address
(IMPL smart contract 1320 (contract address 2)) to generate and
assign to the first designated public address (user 1 public
address 1827) the first amount of digital asset tokens.
[0477] In response to the return call, in embodiments, the fifth
smart contract (IMPL smart contract 1320) may execute via the
blockchain 1807 the first call request to generate a first unique
lock identifier. The fifth smart contract (IMPL smart contract
1320) may return to the second smart contract address (print
limiter 1813) the first unique lock identifier.
[0478] In embodiments, in response to the return of the first
unique lock identifier, the second smart contract (print limiter
1360) may execute, via the blockchain 1807, a second call request
to the fifth smart contract address (IMPL smart contract 1320
(contract address 2)) to confirm the first call request with the
first lock identifier.
[0479] In response to the second call request, in embodiments, the
fifth smart contract (IMPL smart contract 1320) executes, via the
blockchain 1807, the pending first call request to execute a third
call request to the fourth contract address (STORE smart contract
1330 (contract address 4)) to obtain the total supply of digital
asset tokens in circulation.
[0480] In embodiments, the fifth smart contract (IMPL 1320)
executes, via the blockchain network 1807, the call to execute the
first call to execute a second call to the fourth smart contract
(STORE smart contract 1330) to obtain the total supply of digital
asset tokens in circulation. After executing the third call
request, the fourth smart contract (STORE smart contract 1330)
returns, to the fifth contract address (IMPL smart contract 1320
(contract address 2)), a second amount of digital asset tokens
corresponding to the total supply of digital asset tokens in
circulation.
[0481] In response to the return of the second amount, in
embodiments, the fifth smart contract (IMPL smart contract 1320
(contract address 2)) executes via the blockchain 1807 a fourth
call request to the fourth contract address (STORE smart contract
1330 (contract address 4)) to set a new total supply of digital
asset tokens in circulation to a third amount. The third amount, in
embodiments, may be the total of the first amount and the second
amount.
[0482] In embodiments, in response to the fourth call request, the
fourth smart contract (STORE smart contract 1330) executes via the
blockchain 1807 the fourth call request and sets a new total supply
of digital asset tokens in circulation at the third amount. Once
the total supply is set to the third amount, the fourth smart
contract (STORE smart contract 1330) returns to the fifth contract
address (IMPL smart contract 1320 (contract address 2)).
[0483] The fifth smart contract executes, in embodiments, in
response to the return, via the blockchain 1807, a fifth call
request to the fourth contract address (STORE smart contract 1330
(contract address 4)) to add the first amount of digital asset
tokens to the balance associated with the first designated public
address.
[0484] In embodiments, in response to the fifth call request, the
fourth smart contract (STORE smart contract 1330) executes, via the
blockchain 1807, the fifth call request to set the balance of
digital asset tokens in the first designated public address (user 1
public address 1827) at a fourth amount which includes the addition
of the first amount to the previous balance.
[0485] In embodiments, the fourth smart contract (STORE smart
contract 1330) returns to the fifth contract address (IMPL smart
contract 1320 (contract address 2)). Once the fifth contract
address receives the return, in embodiments, the fifth contract
address returns to the second contract address (PRINT LIMITER smart
contract 1360 (contract address 3)).
[0486] The process of FIGS. 21A-B may continue with step S2120. At
step S2120, the digital asset token issuer system confirms the
balance of digital asset tokens in the first designated public
address (user 1 public address 1827) is set to include the first
mount of digital asset tokens based on reference to the
blockchain.
[0487] In embodiments, the steps of FIGS. 21A and 21B may be
rearranged and/or omitted.
EXAMPLE 2
Increase the Token Supply by 10 Million Cents Using an Online Key
(Assumes the Amount to be Printed Would Not Exceed the Ceiling
Limit)
TABLE-US-00009 [0488] Tx 1. TO = address of PrintLimiter DATA =
'limitedPrint(address of User 1, 10,000,000)' (Tx signed by
Administrator.., analogous to above) Execution validates that the
new supply including 10 million cents would not exceed the ceiling.
Next, CALL '(address of Impl.).requestPrint(address of User 1,
10,000,000)' Execution continues in Impl. in function
'requestPrint'. This function produces a unique lock identifier,
say 'lockId2'. Execution returns from Impl. to PrintLimiter,
passing 'lockId2'. Next, in PrintLimiter CALL '(address of
Impl).confirmPrint(lockId2'. Execution continues in Impl. in
function 'confirmPrint'. The pending print associated with
'lockId2' (address of User 1, 10,000,000) is retrieved. Next, CALL
'(address of Store).totalSupply( )' (Execution continues in Store,
in function totalSupply, which returns with the value of the total
supply) let new supply = current supply + 10,000,000 Next, CALL
'(address of Store).setTotalSupply(new supply)' Execution continues
in Store in function 'setTotalSupply'. STORE total supply = new
supply Execution returns to Impl. Next, CALL '(address of
Store).addBalance(address of User 1, 10,000,000)' Execution
continues in Store in function ' addBalance' . STORE balance of
User 1 = balance of User 1 + 10,000,000 Execution returns to Impl.
(some logging occurs, but let's skip over this) Execution returns
to PrintLimiter and terminates.
[0489] In embodiments, the process of FIGS. 21A-B may further
include the process described in connection with FIG. 19D. The
process starts with the blockchain 1807 receiving, from a first
user device associated with the first designated public address via
the blockchain, a second transaction request 1937. The first user
device, may be user device 1 1805. The first designated public
address may be user 1 public address 1827. The second transaction
request may be addressed from the first designated public address
to the first contract address (contract address 1 (proxy smart
contract) 1809). In embodiments, the second transaction request may
include a second message including a second request to transfer a
fifth amount of digital assets from the first designated public
address to a second designated public address. The second
transaction request may be digitally signed by a first user private
key. In embodiments, the first user private key may be
mathematically related to first designated public address (user 1
public address 1827). In embodiments, the first user device 1805
has access to the first user private key prior to sending the
second transaction request. In embodiments, the second transaction
request includes second transaction fee information for miners in
the blockchain network to process the second transaction
request.
[0490] Once the second transaction request is sent, the first smart
contract address (contract address 1 (proxy smart contract) 1809)
executes, via the blockchain 1807, the second transaction request
to execute 1939, via the blockchain 107 a sixth call request to the
fifth contract address (IMPL smart contract 1320 (contract address
2)) to transfer a fifth amount of digital assets form the first
designated public address (User 1 public address 1827) to the
second designated public address (User X public address 1827X). As
shown in FIG. 19D, the proxy smart contract 1310 calls the IMPL
smart contract 1320 to perform a function--transferWithSender(user
1 address, user 2 address, 1000).
[0491] In response to the sixth call request, the fifth smart
contract (IMPL smart contract 1320 (contract address 2)) executes,
via the blockchain 1807, authorization instructions to verify the
sixth call came from an authorized contract address, and, upon
verification, executes a seventh call request 1941 to the fourth
contract address (STORE smart contract 1330 (contract address 4))
to obtain a sixth amount of digital asset tokens which reflect a
current balance of digital asset tokens associated with the first
designated public address. As shown in FIG. 19D, the IMPL smart
contract 1320 calls the STORE smart contract 1330 to determine the
balance associated with the user 1 public address.
[0492] In response to receiving the seventh call request, the
fourth smart contract address (STORE smart contract 1330 (contract
address 4)) executes 1943, via the blockchain 1807, the seventh
call request to return the sixth amount of digital asset tokens. As
shown in FIG. 19D, the store smart contract returns the balance
associated with the user 1 address, which, in the case of the
example shown in connection with FIG. 19D, is 3000.
[0493] In response to the return of the sixth amount of digital
asset, the fifth smart contract (IMPL smart contract 1320 (contract
address 2)) executes 1945, via the blockchain 1807, a balance
verification instruction to confirm that the fifth amount of
digital asset tokens is less than or equal to the sixth amount of
digital asset tokens. In the case where the fifth amount of digital
asset tokens is less than or equal to the sixth amount of digital
asset tokens, the fifth smart contract executes, via the blockchain
network 1807, a seventh call request to the fourth contract address
(STORE smart contract 1330 (contract address 4)) to set a new
balance for the digital asset tokens in the first designated public
address to a seventh amount which equals the sixth amount less the
fifth amount. As shown in FIG. 19D, the IMPL smart contract 1320
verifies that user 1 has a sufficient balance. The user balance in
this example is 3000. The transfer request is for 1000. Thus, user
1 has a sufficient balance to transfer. Once verified, the IMPL
smart contract 1320 sets the user 1 balance at 2000 (the original
user balance 3000 less the transfer request amount 1000).
[0494] In response to the seventh call, the fourth smart contract
(STORE smart contract 1330) executes 1947, via the blockchain 1807,
the seventh call to set and store the new balance for the first
designated public address as the seventh amount and returns the new
balance for the first designated public address as the seventh
amount. As shown in FIG. 19D, the store smart contract sets the
user 1 balance as the seventh amount (2000).
[0495] In response to the return of the new balance, the fifth
smart contract (IMPL smart contract 1320) executes 1949, via the
blockchain 1807, an eighth call to add the second amount of digital
asset tokens to the balance associated with the second designated
public address (User X public address 1827X) at a seventh amount
which includes the addition of the second amount to a previous
balance associated with the second designated public address. As
shown in FIG. 19D, the IMPL smart contract 1320 calls the store
smart contract to add the transfer amount (1000) to the balance
associated with the second user address.
[0496] In response to receiving the either call, the store smart
contract executes the eighth call and sets the balance associated
with the second user to the balance before the transfer and the
transfer amount 1951.
[0497] In embodiments, the STORE smart contract 1330 returns to the
IMPL smart contract 1320. In response to the return, the IMPL smart
contract 1320 may log the new balance associated with the second
user 1953. In embodiments, the IMPL smart contract 1320 may then
return to the proxy smart contract 1310.
[0498] In embodiments, once the transfer has been completed, the
first user device (user 1 device 1805) may confirm that the balance
of digital asset tokens in the first designated public address is
the sixth amount of digital asset tokens based on reference to the
blockchain 1807. Similarly, the second user device (user X device
1805X) may also confirm that the balance of digital asset tokens in
the second designated public address is the seventh amount of
digital asset tokens based on reference to the blockchain 1807.
EXAMPLE
User 1 Transfers 1,000 Cents to User 2
TABLE-US-00010 [0499] Tx 1. TO = address of Proxy DATA =
'transfer(address of User 2, 1,000)' Tx signed by User 1 private
key, therefore FROM = address of User 1 public key Execution
immediately jumps to Impl. CALL '(address of
Impl.).transferWithSender(address of User 1, address of User 2,
1,000)' Execution continues in Impl. in function
'transferWithSender'. This function validates that it was called by
the sender it trusts, so it checks that sender is address of Proxy.
Next, CALL '(address of Store).balances(address of User 1)'
(Execution continues in Store, in function 'balances', which
returns the balance associated with the address of User 1)
Execution returns and continues in Impl where the retrieved balance
value is compared to 1,000 to check that User 1 has at least 1,000
tokens. let new balance of User 1 = balance of User 1 - 1,000 Next,
CALL '(address of Store).setBalance(address of User 1, new balance
of User 1)' Execution continues in Store in function ' setBalance'.
(function checks that it was called by the sender it trusts, the
active Impl.) STORE balance of User 1 = new balance of User 1
Execution returns to Impl. Next, CALL '(address of
Store).addBalance(address of User 2, 1,000)' Execution continues in
Store in function ' addBalance'. (function checks that it was
called by the sender it trusts...) STORE balance of User 2 =
balance of User 2 + 1,000 Execution returns to Impl. (some logging
occurs, but let's skip over this) Execution returns to Proxy and
terminates.
[0500] In embodiments, the process of FIGS. 21A-B may further
include the process described in connection with FIG. 19E. In
embodiments, the process may begin with providing a third
designated key pair. The third designated key pair, in embodiments,
may include a third designated public key of the underlying digital
asset and a corresponding third designated private key. The third
designated private key may be stored on a third computer system
which is connected to the distributed public transaction ledger
through the internet (network 15). In embodiments, the third
designated key pair may be the first designated key pair. In
embodiments, the third designated key pair may be the second
designated key pair. In embodiments, the third computer system may
be the first computer system. In embodiments, the third computer
system is not the first computer system. In embodiments, the
administrator system 1801 includes the first computer system and
the third computer system.
[0501] The blockchain 1807 may receive a second transaction request
1955 by the blockchain 1807 from the third computer system (i.e.
user device 1). The second transaction request may include a second
message including a second request to burn a fifth amount of
digital asset tokens from a balance associated with the third
designated public key address. The second transaction request may
be sent from the third designated public key address to the fifth
contract address (IMPL smart contract 1320 (contract address 2)).
The second transaction request, in embodiments, is digitally signed
by a third designated private key.
[0502] In response to receiving the second transaction request, the
fifth smart contract (IMPL smart contract 1320) executes 1957, via
the blockchain 1807, the second transaction request to execute, via
the blockchain 1807, a sixth call request to the fourth contract
address (STORE smart contract 1330 (contract address 4)) to obtain
a sixth amount of digital asset tokens which reflect a current
balance of digital asset tokens associated with the third
designated public key address. As shown in FIG. 19E, the IMPL smart
contract 1320 calls the store contract address 1815 to request a
balance of digital asset tokens associated with the third
designated public address (address 1).
[0503] In response to the sixth call request, the fourth smart
contract (STORE smart contract 1330), executes 1959 via the
blockchain 1807, the seventh call request to return the sixth
amount of digital asset tokens. As shown in FIG. 19E, the STORE
smart contract 1330 determines that the balance associated with the
third designated public address is 3000. The STORE smart contract
1330 returns the amount (3000) to the IMPL smart contract 1320.
[0504] In response to the return of the sixth amount of digital
asset, the fifth smart contract (IMPL smart contract 1320) executes
1961, via the blockchain 1807, a balance verification instruction
to confirm that the fifth amount of digital asset tokens is less
than or equal to the sixth amount of digital asset tokens. In the
case where the fifth amount of digital asset tokens is less than or
equal to the sixth amount of digital asset tokens, the fifth smart
contract (IMPL smart contract 1320) executes, via the blockchain
1807, a seventh call request to the fourth contract address (STORE
smart contract 1330 (contract address 4)) to set a new balance for
the digital asset tokens in the third designated public key address
to a seventh amount which equals the sixth amount less the fifth
amount. As shown in FIG. 19E, the IMPL smart contract 1320 verifies
that the third designated public address (address 1) has as
sufficient balance because 1000 is less than the current balance of
3000. The IMPL smart contract 1320 then executes a call to set the
balance of associated with the third designated public address
(address 1) to 2000 (3000 less 1000 equals 2000).
[0505] In response to the seventh call, the fourth smart contract
(STORE smart contract 1330) executes 1963, via the blockchain 1807,
the seventh call to set and store the new balance for the third
designated public key address as the seventh amount and returns the
new balance for the third designated public key address as the
seventh amount. As shown in FIG. 19E, the STORE smart contract 1330
stores the new balance as 2000 and returns to the IMPL smart
contract 1320.
[0506] In response to the return of the new balance, the fifth
smart contract (IMPL smart contract 1320) executes 1965, via the
blockchain 1807, an eighth call request to the fourth contract
address (STORE smart contract 1330 (contract address 4)) to obtain
a total supply of digital asset tokens in circulation. As shown in
FIG. 19E, the IMPL smart contract 1320 calls the STORE smart
contract 1330, requesting a total supply of digital asset
tokens.
[0507] In response to the eighth call request, the fourth smart
contract (STORE smart contract 1330) executes 1967, via the
blockchain 1807 the eight call request and returns, to the fifth
contract address (IMPL smart contract 1320 (contract address 2)),
an eighth amount of digital asset tokens corresponding to the total
supply of digital asset tokens in circulation. As shown in FIG.
19E, the STORE smart contract 1330 determines that the total supply
of tokens is 10,000 and returns that value to the IMPL smart
contract 1320.
[0508] In response to the return of the eighth amount, the fifth
smart contract (IMPL smart contract 1320) executes 1969, via the
blockchain, a ninth call request to the fourth contract address
(STORE smart contract 1330 (contract address 4)) to set a new total
supply of digital asset tokens in circulation to a ninth amount,
which is the eighth amount less the fifth amount. As shown in FIG.
19E, the IMPL smart contract 1320 calls the STORE smart contract
1330 to set the total supply of the digital asset tokens to 9,000
(10,000 less 1,000).
[0509] In response to the ninth call request, the fourth smart
contract (STORE smart contract 1330) executes 1971, via the
blockchain 1807, the ninth call request and sets a new total supply
of digital asset tokens in circulation at the ninth amount and
returns to the fifth contract address (IMPL smart contract 1320
(contract address 2)). In embodiments, the token balance
modification instructions module 1847 balances the deposits and
withdrawals at a predetermined time (i.e. end of the day or close
of business).
[0510] In response to receiving a return from the STORE smart
contract 1330, the IMPL smart contract 1320 logs 1973 the new total
supply of digital asset tokens in circulation.
EXAMPLE
Reduce the Token Supply by 1,000,000 Cents
TABLE-US-00011 [0511] Tx 1. TO = address of Impl. DATA =
'burn(1,000,000)' (Tx is signed by the key of the address that is
going to sacrifice some of its balance.) let address of sender =
address of key that signed Tx 1. Execution immediately jumps to
Store CALL '(address of Store).balances(address of sender)'
(Execution continues in Store, in function 'balances', which
returns the balance associated with the sender) Execution returns
and continues in Impl where the retrieved balance value is compared
to the burn amount of 1,000,000 to check that the sender has at
least 1,000,000 tokens. let new balance of sender = balance of
sender - 1,000,000 Next, CALL '(address of
Store).setBalance(address of sender, new balance of sender)'
Execution continues in Store in function 'setBalance'. (function
checks that it was called by the sender it trusts, the active
Impl.) STORE balance of sender = new balance of sender Execution
returns to Impl. Next, Call '(address of Store).totalSupply( )'
(Execution continues in Store, in function 'totalSupply', which
returns with the value of the total supply) let new supply =
current supply + 1,000,000 Next, CALL '(address of
Store).setTotalSupply(new supply)' Execution continues in Store in
function 'setTotal Supply'. STORE total supply = new supply
Execution returns to Impl. (some logging occurs, but let's skip
over this) And execution terminates.
EXAMPLE
Change the Impl that Proxy Delegates to
TABLE-US-00012 [0512] Tx 1. TO = address of Proxy DATA =
'requestImplChange( address of Impl_V2)' (Tx would be signed by
Adminstrator's `primary` key, although there are no restrictions on
who can call this function.) Execution produces a unique lock
identifier, say 'lockId3'.
TABLE-US-00013 Tx 2. TO = address of (Upgrade)Custodian (instance
of the Custodian contract, with cryo tier keys, intended to be the
offline custodian of upgrade operations) DATA =
'requestUnlock(lockId3, address of Proxy, selector for function
confirmImplChange,...and a detail I'm going to omit...)' (Tx would
be signed by Adminstrator's 'primary' key, although there are no
restrictions on who can call this function. If it's a not the
primary key there is an anti-spam mechanism.) Execution produces a
unique request hash, say 'reqMsgHash2'. 2 of the offline keys set
up with (Upgrade)Custodian sign 'reqMsgHash2'; we'll name the
signatures 'sig2_a' and ' sig2_b'. Tx 3. TO = address of
(Upgrade)Custodian DATA = 'completeUnlock(requestMsgHash2, sig2_a,
sig2_b)' (Tx would be signed by Adminstrator's `primary`key,
although there are no restrictions on who can call this function.)
Execution validates the signatures (and enforces other details
around time locks and revocation). Next, it executes a call to
Proxy and its confirmImplChange (NOTE that those two detailed were
fixed in Tx2 as parameters to the call to requestUnlock). CALL
'(address of Proxy).confirmImplChange(lockId3)' Execution continues
in PrintLimiter in the function 'confirmImplChange'. Storage for
the active implementation address is updated: STORE impl = address
of Impl_V2 (some logging occurs, but let's skip over this)
Execution returns to (Upgrade)Custodian (some logging occurs, but
let's skip over this) Execution terminates.
[0513] FIG. 19C is a schematic drawing of an exemplary process of
limiting the print limiter with respect to a public address in
accordance with exemplary embodiments of the present invention. The
process at FIG. 19C may begin with a first transaction request 1917
by an administrator system 1801 to blockchain 1807. The first
transaction request may be from on-line key public address 1825 to
PRINT LIMITER smart contract 1360 (contract address 3). In
embodiments, the first transaction request may include a message
requesting the limited print of 10 million digital asset tokens to
user 1 public address 1827.
[0514] In response to receiving the first transaction request, the
PRINT LIMITER smart contract 1360 executes 1919 a first call
request, via the blockchain 1807, to the impl smart contract
address 1811 to print 10 million digital asset tokens to user 1
public address 1827. In response to receiving the first call
request, the impl returns a lockID 1921 to the print limiter smart
contract address 1813.
[0515] In response to receiving the lockID, the print limiter smart
contract executes 1923 a second call request, via the blockchain
1807, to the impl smart contract address 1811 to confirm the print
of 10 million digital asset tokens using the lockID.
[0516] In response to receiving the second call, the IMPL smart
contract 1320 retrieves the pending request to print 10 million
digital asset tokens and executes 1925, via the blockchain 1807, a
third call request to the store smart contract address 1815 to
determine the total supply of digital asset tokens.
[0517] In response to receiving the third call, the STORE smart
contract 1330 determines 1927 the total supply of digital asset
tokens to be 100 million digital asset tokens. The total supply
amount determined by the STORE smart contract 1330 is then returned
by the STORE smart contract 1330 to the impl smart contract address
1811.
[0518] In response to receiving the return from the store smart
contract address 1815, the impl smart contract address executes
1929, via the blockchain, a fourth call request to set the total
supply of digital asset tokens to 110 million, the original total
supply 100 million plus the requested print amount of 10 million.
The fourth call request may be sent to the store smart contract
address 1815.
[0519] In response to receiving the fourth call request, the STORE
smart contract 1330 sets 1931 the total supply of digital asset
tokens to 110 million digital asset tokens and returns to the impl
smart contract address 1811.
[0520] In response to receiving the return from the store smart
contract address 1815, the impl smart contract may execute 1933 a
fifth call to add the newly printed 10 million digital asset tokens
to user 1 public address 1827. The call may be sent to the store
smart contract address 1815.
[0521] In response to receiving the fifth call to add the 10
million digital asset tokens to user 1 public address 1827, the
STORE smart contract 1330 may store 1935 a new balance associated
with the user 1 public address 1827, the new balance being the
original balance plus the 10 million digital asset tokens. The
STORE smart contract 1330 may then return to the impl smart
contract address 1811. In response to receiving the return from the
STORE smart contract 1330, the impl smart contract may return to
the print limiter smart contract public address 1813.
[0522] In embodiments, the steps of FIGS. 19A through 19E may be
rearranged and/or omitted. In embodiments, any of the smart
contracts may be provided at any of the contract addresses, for
example, the fourth contract address may correspond to the IMPL
smart contract while fifth contract address may correspond to the
STORE smart contract. In embodiments, one or more smart contract
may be combined with one of more other smart contract.
Blockchain Based Financial Instrument
[0523] In embodiments, a digital asset in the form of a token
("Security Token") may be issued to represent inventory, equity
interests in a venture, real estate, rights in intellectual
property such music, videos, pictures, to name a few. When used as
a security, appropriate filings with a regulatory authority may be
necessary to comply with local law. In the case of a security,
investors may exchange fiat or other digital assets (such as
bitcoin or ether, to name a few) in exchange for Security Tokens.
Typically, Security Tokens may issue using a smart contract written
on another digital asset (such as ether or bitcoin, to name a few),
and tracked in a separate database stored in a distributed peer to
peer network in the form of a blockchain. In an example, the
blockchain is the Ethereum Blockchain and includes all Security
Tokens, the respective address associated therewith, wherein
maintenance of the blockchain is controlled by contract
instructions stored in the form of a smart contract at the Contract
Address. In embodiments, the Secure Token database maintained on
the blockchain may be viewed via etherscan.io. In embodiments, the
Security Token ledger may be maintained as a sidechain in a
separate database off chain and published periodically or
aperiodically to the blockchain. Each Security Token may also be
associated with a specific digital asset address on the network
associated with the underlying digital asset (e.g., the Ethereum
Network when ether is the underlying digital asset, or the Bitcoin
Network, when bitcoin is the digital asset, to name a few).
Generally, the same blockchain will be used for the SVCoin and the
Security Token.
Digital Asset Accounts and Transaction Security
[0524] Digital assets may be associated with a digital asset
account, which may be identified by a digital asset address. A
digital asset account can comprise at least one public key and at
least one private key, e.g., based on a cryptographic protocol
associated with the particular digital asset system, as discussed
herein. One or more digital asset accounts may be accessed and/or
stored using a digital wallet, and the accounts may be accessed
through the wallet using the keys corresponding to the account.
Public Keys
[0525] A digital asset account identifier and/or a digital wallet
identifier may comprise a public key and/or a public address. Such
a digital asset account identifier may be used to identify an
account in transactions, e.g., by listing the digital asset account
identifier on a decentralized electronic ledger (e.g., in
association with one or more digital asset transactions), by
specifying the digital asset account identifier as an origin
account identifier, and/or by specifying the digital asset account
identifier as a destination account identifier, to name a few. The
systems and methods described herein involving public keys and/or
public addresses are not intended to exclude one or the other and
are instead intended generally to refer to digital asset account
identifiers, as may be used for other digital math-based asset. A
public key may be a key (e.g., a sequence, such as a binary
sequence or an alphanumeric sequence) that can be publicly revealed
while maintaining security, as the public key alone cannot decrypt
or access a corresponding account. A public address may be a
version of a public key. In embodiments, a public key may be
generated from a private key, e.g., using a cryptographic protocol,
such as the Elliptic Curve Digital Signature Algorithm
("ECDSA").
[0526] In exemplary embodiments using bitcoin, a public key may be
a 512-bit key, which may be converted to a 160-bit key using a
hash, such as the SHA-256 and/or RIPEMD-160 hash algorithms. The
160-bit key may be encoded from binary to text, e.g., using Base58
encoding, to produce a public address comprising non-binary text
(e.g., an alphanumeric sequence). Accordingly, in embodiments, a
public address may comprise a version (e.g., a shortened yet not
truncated version) of a public key, which may be derived from the
public key via hashing or other encoding. In embodiments, a public
address for a digital wallet may comprise human-readable strings of
numbers and letters around 34 characters in length, beginning with
the digit 1 or 3, as in the example of
175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W. The matching private key may be
stored in a digital wallet or mobile device and protected by a
password or other techniques and/or devices for providing
authentication.
[0527] In embodiments, other cryptographic algorithms may be used
such as: [0528] (1) The elliptic curve Diffie-Hellman (ECDH) key
agreement scheme; [0529] (2) The Elliptic Curve Integrated
Encryption Scheme (ECIES), also known as Elliptic Curve Augmented
Encryption Scheme or simply the Elliptic Curve Encryption Scheme;
[0530] (3) The Elliptic Curve Digital Signature Algorithm (ECDSA)
which is based on the Digital Signature Algorithm; [0531] (4) The
deformation scheme using Harrison's p-adic Manhattan metric; [0532]
(5) The Edwards-curve Digital Signature Algorithm (EdDSA) which is
based on Schnorr signature and uses twisted Edwards curves; [0533]
(6) The ECMQV key agreement scheme which is based on the MQV key
agreement scheme; and [0534] (7) The ECQV implicit certificate
scheme.
[0535] In other digital asset networks, other nomenclature
mechanisms may be used, such as a human-readable string of numbers
and letters around 34 characters in length, beginning with the
letter L for Litecoin or M or N for Namecoin or around 44
characters in length, beginning with the letter P for PPCoin, to
name a few.
Private Keys
[0536] A private key in the context of a digital math-based asset,
such as bitcoin, may be a sequence such as a number that allows the
digital math-based asset, e.g., bitcoin, to be transferred or
spent. In embodiments, a private key may be kept secret to help
protect against unauthorized transactions. In a digital asset
system, a private key may correspond to a digital asset account,
which may also have a public key or other digital asset account
identifier. While the public key may be derived from the private
key, the reverse may not be true.
[0537] In embodiments related to the Bitcoin system, every Bitcoin
public address has a matching private key, which can be saved in
the digital wallet file of the account holder. The private key can
be mathematically related to the Bitcoin public address and can be
designed so that the Bitcoin public address can be calculated from
the private key, but importantly, the same cannot be done in
reverse. In the event that a transaction is sent to a Bitcoin
public address and signed by a private key that does not match,
such transaction will not be processed by the Bitcoin
blockchain.
[0538] A digital asset account, such as a multi-signature account,
may require a plurality of private keys to access it. In
embodiments, any number of private keys may be required. An account
creator may specify the number of required keys (e.g., 2, 3, 5, to
name a few) when generating a new account. More keys may be
generated than are required to access and/or use an account. For
example, 5 keys may be generated, and any combination of 3 of the 5
keys may be sufficient to access a digital asset account. Such an
account setup can allow for additional storage and security
options, such as backup keys and multi-signature transaction
approval, as described herein.
[0539] Because a private key provides authorization to transfer or
spend digital assets such as bitcoin, security of the private key
can be important. Private keys can be stored via electronic
computer files, but they may also be short enough that they can be
printed or otherwise written on paper or other media. An example of
a utility that allows extraction of private keys from an electronic
wallet file for printing purposes is Pywallet. Other extraction
utilities may also be used consistent with the present
invention.
[0540] In embodiments, a private key can be made available to a
program or service that allows entry or importing of private keys
in order to process a transaction from an account associated with
the corresponding public key. Some wallets can allow the private
key to be imported without generating any transactions while other
wallets or services may require that the private key be swept. When
a private key is swept, a transaction is automatically broadcast so
that the entire balance held by the private key is sent or
transferred to another address in the wallet and/or securely
controlled by the service in question.
[0541] In embodiments, using Bitcoin clients, such as
BlockChain.info's My Wallet service and Bitcoin-QT, a private key
may be imported without creating a sweep transaction.
[0542] In embodiments, a private key, such as for a Bitcoin
account, may be a 256-bit number, which can be represented in one
or more ways. For example, a private key in a hexadecimal format
may be shorter than in a decimal format. For example, 256 bits in
hexadecimal is 32 bytes, or 64 characters in the range 0-9 or A-F.
The following is an example of a hexadecimal private key: [0543] E9
87 3D 79 C6 D8 7D C0 FB 6A 57 78 63 33 89 F4 45 32 13 30 3D A6 1F
20 BD 67 FC 23 3A A3 32 62
[0544] In embodiments, nearly every 256-bit number is a valid
private key. Specifically, any 256-bit number between 0x1 and
0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2
5E8C D036 4141 is a valid private key. In embodiments, the range of
valid private keys can be governed by the secp256k1 ECDSA standard
used by Bitcoin. Other standards may also be used.
[0545] In embodiments, a shorter form of a private key may be used,
such as a base 58 Wallet Import format, which may be derived from
the private key using Base58 and/or Base58Check encoding. The
Wallet Import format may be shorter than the original private key
and can include built-in error checking codes so that typographical
errors can be automatically detected and/or corrected. For private
keys associated with uncompressed public keys, the private key may
be 51 characters and may start with the number 5. For example, such
a private key may be in the following format: [0546]
5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF
[0547] In embodiments, private keys associated with compressed
public keys may be 52 characters and start with a capital L or
K.
[0548] In embodiments, when a private key is imported, each private
key may always correspond to exactly one Bitcoin public address. In
embodiments, a utility that performs the conversion can display the
matching Bitcoin public address.
[0549] The Bitcoin public address corresponding to the sample above
is: [0550] 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj
[0551] In embodiments, a mini private key format can be used. Not
every private key or Bitcoin public address has a corresponding
mini private key; they have to be generated a certain way in order
to ensure a mini private key exists for an address. The mini
private key is used for applications where space is critical, such
as in QR codes and in physical bitcoin. The above example has a
mini key, which is: [0552] SzavMBLoXU6kDrqtUVmffv
[0553] In embodiments, any bitcoin sent to the designated address
1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj can be transferred or spent by
anybody who knows the private key in any of the three formats
(e.g., hexadecimal, base 58 wallet format, or mini private key).
That includes bitcoin presently at the address, as well as any
bitcoin that are ever sent to it in the future. The private key is
only needed to transfer or spend the balance, not necessarily to
see it. In embodiments, the bitcoin balance of the address can be
determined by anybody with the public Block Explorer at
http://www.blockexplorer.com/address/lCC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj---
even if without access to the private key.
[0554] In embodiments, a private key may be divided into segments,
encrypted, printed, and/or stored in other formats and/or other
media, as discussed herein.
Digital Wallets
[0555] In embodiments, digital math-based assets can be stored
and/or transferred using either a website or software, such as
downloaded software. The website and/or downloadable software may
comprise and/or provide access to a digital wallet. Each digital
wallet can have one or more individual digital asset accounts
(e.g., digital asset addresses) associated with it. Each user can
have one or more digital wallets to store digital math-based
assets, digital cryptocurrency, assets and the like and/or perform
transactions involving those currencies or assets. In embodiments,
service providers can provide services that are tied to a user's
individual account.
[0556] Digital wallets and/or the digital asset accounts associated
with and/or stored by a digital wallet may be accessed using the
private key (which may be used in conjunction with a public key or
variant thereof). Accordingly, the generation, access, use, and
storage of digital asset accounts is described herein with respect
to generation, access, use, and storage of digital wallets. Such
descriptions are intended to be representative of digital asset
accounts and not exclusive thereof.
[0557] A digital wallet can be generated using a digital asset
client 110 (e.g., a Bitcoin client). In embodiments, a digital
wallet can be created using a key pair system, such as an
asymmetric key pair like a public key and a private key. The public
key can be shared with others to designate the address of a user's
individual account and/or can be used by registries and/or others
to track digital math-based asset transactions involving a digital
asset account associated with the digital wallet. Such transactions
may be listed or otherwise identified by the digital wallet. The
public key may be used to designate a recipient of a digital asset
transaction. A corresponding private key can be held by the account
holder in secret to access the digital wallet and perform
transactions. In embodiments, a private key may be a 256-bit
number, which can be represented by a 64-character hexadecimal
private key and/or a 51-character base-58 private key. As discussed
herein, private keys of other lengths and/or based on other
numbering systems can be used, depending upon the user's desire to
maintain a certain level of security and convenience. Other forms
of key pairs, or security measures can be used consistent with
embodiments of the present invention.
[0558] In embodiments, a digital wallet may store one or more
private keys or one or more key pairs which may correspond to one
or more digital asset accounts.
[0559] In embodiments, a digital wallet may be a computer software
wallet, which may be installed on a computer. The user of a
computer software wallet may be responsible for performing backups
of the wallet, e.g., to protect against loss or destruction,
particularly of the private and/or public key. In embodiments, a
digital wallet may be a mobile wallet, which may operate on a
mobile device (e.g., mobile phone, smart phone, cell phone, iPod
Touch, PDA, tablet, portable computer, to name a few). In
embodiments, a digital wallet may be a website wallet or a web
wallet. A user of a web wallet may not be required to perform
backups, as the web wallet may be responsible for storage of
digital assets. Different wallet clients may be provided, which may
offer different performance and/or features in terms of, e.g.,
security, backup options, connectivity to banks or digital asset
exchanges, user interface, and/or speed, to name a few.
[0560] In embodiments, a digital wallet may be a custodial digital
wallet. Further, the custodial digital wallet may be a segregated
custodial wallet or a commingled custodial wallet. Segregated
custodial digital wallets hold digital assets for the benefit of a
single customer or entity. Commingled custodial accounts hold
digital assets for multiple users or customers of the custodian.
Segregated custodial wallets are useful for institutional clients,
mutual funds and hedge funds, for example.
[0561] While many digital asset holders may hold their digital
assets in their own wallets, various custodial services, like
Gemini custodial services exist. In embodiments, the present
invention may be used with custodial wallets. In embodiments,
custodial wallets may be commingled custodial wallets which
commingle digital assets from more than one client. In embodiments,
custodial wallets may be segregated custodial wallets, in which
digital assets for a specific client is held using one or more
unique digital asset addresses maintained by the custodial service.
For segregated custodial wallets, the amount of digital assets held
in such wallet(s) may be verified and audited on their respective
blockchain. In embodiments, segregated custodial accounts may be
used for digital asset holders such as hedge funds, mutual funds,
exchange traded funds, to name a few. Proof of control as described
herein may be implemented to verify the amount of assets held in
custodial wallets, including both segregated custodial wallets and
commingled custodial wallets.
Signatures
[0562] A transaction may require, as a precondition to execution, a
digital asset signature generated using a private key and
associated public key for the digital asset account making the
transfer. In embodiments, each transaction can be signed by a
digital wallet or other storage mechanism of a user sending a
transaction by utilizing a private key associated with such a
digital wallet. The signature may provide authorization for the
transaction to proceed, e.g., authorization to broadcast the
transaction to a digital asset network and/or authorization for
other users in a digital asset network to accept the transaction. A
signature can be a number that proves that a signing operation took
place. A signature can be mathematically generated from a hash of
something to be signed, plus a private key. The signature itself
can be two numbers such as r and s. With the public key, a
mathematical algorithm can be used on the signature to determine
that it was originally produced from the hash and the private key,
without needing to know the private key. Signatures can be either
73, 72, or 71 bytes long, to name a few.
[0563] In embodiments, the ECDSA cryptographic algorithm may be
used to ensure that digital asset transactions (e.g., bitcoin
transactions) can only be initiated from the digital wallet holding
the digital assets (e.g., bitcoin). Alternatively, or in addition,
other algorithms may be employed.
[0564] In embodiments, a transaction from a multi-signature account
may require digital asset signatures from a plurality of private
keys, which may correspond to the same public key and/or public
address identifying the multi-signature digital asset account. As
described herein, a greater number of private keys may be created
than is necessary to sign a transaction (e.g., 5 private keys
created and only 3 required to sign a transaction). In embodiments,
private keys for a multi-signature account may be distributed to a
plurality of users who are required to authorize a transaction
together. In embodiments, private keys for a multi-signature
account may be stored as backups, e.g., in secure storage, which
may be difficult to access, and may be used in the event that more
readily obtainable keys are lost. As noted above, there are a
variety of cryptographic algorithms that may be used.
Market Places
[0565] A digital asset market place, such as a Bitcoin market
place, can comprise various participants, including users, vendors,
exchanges, exchange agents, and/or miners/mining pools. The market
contains a number of digital asset exchanges, which facilitate
trade of digital assets using other currencies, such as United
States dollars. Exchanges may allow market participants to buy and
sell digital assets, essentially converting between digital assets
(e.g., bitcoin) and currency, legal tender, and/or traditional
money (e.g., cash). In embodiments, a digital asset exchange market
can include a global exchange market for the trading of digital
assets, which may contain transactions on electronic exchange
markets. In embodiments, a digital asset exchange market can also
include regional exchange markets for the trading of digital
assets, which may contain transactions on electronic exchange
markets. In accordance with the present invention, exchanges and/or
transmitters may also be used to facilitate other transactions
involving digital assets, such as where digital assets are being
transferred from differently denominated accounts or where the
amount to transfer is specified in a different denomination than
the digital asset being transferred, to name a few. Gemini Trust
Company LLC ("Gemini") at (www.gemini.com) is an example of a
digital asset exchange 130. By example, registered users of Gemini
may buy and sell digital assets such as Bitcoin and Ether in
exchange for fiat such as U.S. dollars or other digital assets,
such as Ether and Bitcoin, respectively. A Bitcoin exchange agent
135 can be a service that acts as an agent for exchanges,
accelerating the buying and selling of bitcoin as well as the
transfer of funds to be used in the buying and/or selling of
bitcoin. Coinbase is an example of a company that performs the role
of a Bitcoin exchange agent 135. Coinbase engages in the retail
sale of bitcoin, which it obtains, at least in part, from one or
more exchanges. FIG. 3 illustrates an exemplary Coinbase website
interface for buying bitcoin. Other Coinbase options include "Sell
Bitcoin," "Send Money," "Request Money," and "Recurring Payments."
Other options could also be made available consistent with
exemplary embodiments of the present invention.
[0566] In addition to the services that facilitate digital asset
transactions and exchanges with cash, digital asset transactions
can occur directly between two users. In exemplary uses, one user
may provide payment of a certain number of digital assets to
another user. Such a transfer may occur by using digital wallets
and designating the public key of the wallet to which funds are
being transferred. As a result of the capability, digital assets
may form the basis of business and other transactions. Digital
math-based asset transactions may occur on a global scale without
the added costs, complexities, time and/or other limits associated
with using one or more different currencies.
[0567] Vendors 140 may accept digital assets as payment. A vendor
140 may be a seller with a digital wallet that can hold the digital
asset. In embodiments, a vendor may use a custodial wallet. In
embodiments, a vendor 140 may be a larger institution with an
infrastructure arranged to accept and/or transact in digital
assets. Various vendors 140 can offer banknotes and coins
denominated in bitcoin; what is sold is really a Bitcoin private
key as part of the coin or banknote. Usually, a seal has to be
broken to access the Bitcoin private key, while the receiving
address remains visible on the outside so that the bitcoin balance
can be verified. In embodiments, a debit card can be tied to a
Bitcoin wallet to process transactions.
Digital Asset Exchange
[0568] In embodiments, one form of trusted entity that may be an
issuer of SVCoin or an agent of the issuer is a digital asset
exchange or bank. In embodiments, the trusted entity may maintain
an SVCoin database on a blockchain. In embodiments, the trusted
entity may maintain the SVCoin database off chain as a sidechain
which may be periodically or aperiodically published to a
blockchain as discussed elsewhere.
[0569] In some embodiments, the trusted entity may be a digital
asset exchange. A digital asset exchange, such as a digital
math-based asset exchange, may allow users to sell digital assets
in exchange for any other digital assets or fiat currency and/or
may allow users to sell fiat currency in exchange for any digital
assets. Accordingly, an exchange may allow users to buy digital
assets in exchange for other digital assets or fiat currency and/or
to buy fiat currency in exchange for digital assets. In
embodiments, a digital asset exchange may integrate with a foreign
exchange market or platform. A digital asset exchange may be
configured as a centralized exchange or a decentralized exchange,
as discussed herein.
[0570] In embodiments, the issuer of the SVCoin may be a digital
asset exchange, a bank, a trust, or other trusted entity. In the
context where a digital asset exchange may act as an issuer for
SVCoin, or as an agent of the issuer, a digital asset exchange
computer system may maintain a ledger as one or more databases
associated with the SVCoin. Such a database may include an
electronic log of all transactions, including the source wallet,
the destination wallet, the timestamp of the transaction, the
amount of the transaction (e.g., the number of SVCoin), and/or the
balance in each wallet before and/or after the transaction. In
embodiments, the database may include a list of wallet addresses
and balances in each wallet of the SV Coin. In embodiments, the
issuer may maintain the database by using a smart contract in
association with a Contract Digital Address as part of a blockchain
network, such as the Ethereum Network. In embodiments, the ledger
may be maintained in a database as a sidechain which is
periodically, or aperiodically, published to a blockchain such as
the Ethereum blockchain. In embodiments, the ledger may be
maintained directly on the blockchain.
[0571] FIG. 3 is a schematic diagram illustrating various potential
participants in a digital asset exchange, in exemplary embodiments.
The participants may be connected directly and/or indirectly, such
as through a data network 15, as discussed herein. Users of a
digital asset exchange may be customers of the exchange, such as
digital asset buyers and/or digital asset sellers. Digital asset
buyers may pay fiat (e.g., USD, Euro, Yen, to name a few) in
exchange for digital assets (e.g., bitcoin, ether, litecoin,
dogecoin, to name a few). Digital asset sellers may exchange
digital assets (e.g., bitcoin, ether, litecoin, dogecoin, to name a
few) for fiat (e.g., USD, Euro, Yen, to name a few). In
embodiments, instead of fiat, other forms of digital assets may
also be used.
[0572] In embodiments, users may connect to the exchange through
one or more user electronic devices 3202 (e.g., 3202-1, 3202-2, . .
. , 3202-N), such as computers, laptops, tablet computers,
televisions, mobile phones, smartphones, and/or PDAs, to name a
few. A user electronic device 3202 may access, connect to, and/or
otherwise run one or more user digital wallets 3204. In
embodiments, buyers and/or sellers may access the exchange using
their own electronic devices and/or through a digital asset kiosk.
A digital asset enabled kiosk can receive cash, including notes,
coins or other legal tender, (of one or more fiat currencies) from
a buyer to use in buying a quantity of digital assets. A digital
asset kiosk may dispense cash (of one or more fiat currencies) to a
seller of digital assets. In embodiments, a digital asset kiosk may
receive funds from and/or dispense funds to a card, such as a
prepaid or reloadable card, digital asset address associated with a
digital wallet, or electronic account. In embodiments, a digital
wallet may be stored on a user electronic device, such as a mobile
electronic device, or other computing device.
[0573] Users may also have user bank accounts 3208 held at one or
more banks 3206. In embodiments, users may be able to access their
bank accounts from a user electronic device 3202 and/or from a
digital wallet 3204 or digital address associated therewith.
[0574] A digital asset exchange computer system 3210 can include
software running on one or more processors, as discussed herein, as
well as computer-readable memory comprising one or more database. A
digital asset exchange can include one or more exchange digital
wallets 3212, e.g., digital wallet 3212-A. Exchange digital wallets
may be used to store digital assets in one or more denominations
from one or more parties to a transaction. In embodiments, exchange
digital wallets may store digital assets owned by the exchange,
which may be used where an exchange is a counter-party to an
exchange transaction, which can allow exchange transactions to
occur even when a buyer and a seller are not otherwise both
available and in agreement on transaction terms.
[0575] A digital asset exchange may have one or more bank accounts,
e.g., bank account 3216-A, held at one or more banks 3214, such as
exchange banks or exchange partner banks, which are banks
associated with and/or in partnership with the exchange. In
embodiments, exchanges may access other repositories for fiat
currency. An exchange bank account may be a pass-through account
that receives fiat currency deposits from a digital asset buyer and
transfers the fiat currency to a digital asset seller. The exchange
bank account may hold money in escrow while an exchange transaction
is pending. For example, the exchange bank account may hold a
digital asset buyer's fiat currency until a digital asset seller
transfers digital assets to a buyer, to an exchange, or to an
authorized third party. Upon receipt by the appropriate recipient
of the requisite amount of digital assets, the exchange may
authorize the release of the fiat currency to the digital asset
seller. In embodiments, an exchange may hold, e.g., as custodian,
fiat in bank accounts and digital assets in digital wallets at
associated digital asset addresses. In embodiments, instead of
using bank accounts, other stable investment instruments such as
money market mutual funds, treasury bills, certificates of
deposits, low risk bonds, to name a few, may be used.
[0576] FIG. 4A is another schematic diagram illustrating entities
associated with a digital asset exchange in an exemplary embodiment
of the present invention. Each entity may operate one or more
computer systems. Computer systems may be connected directly or
indirectly, such as through a data network. Entities associated
with a digital asset exchange can include the exchange, an exchange
computer system 3230, customer digital asset wallets at associated
digital asset addresses 3222 (e.g., bitcoin wallets, ether wallets,
to name a few), customer bank(s) 3224 having a customer fiat bank
account(s) 3226, a digital asset network ledger 3228 (e.g., the
Bitcoin blockchain, the Ethereum blockchain, to name a few), a
digital asset network (e.g., the Bitcoin Network, the Ethereum
Network, to name a few), one or more exchange customers using one
or more customer user devices 3232, an exchange digital asset
electronic ledger 3234, one or more exchange digital asset vaults
3238, an exchange fiat electronic ledger 3236, and one or more
exchange partner banks 3242, which can have exchange pooled
customer fiat accounts 3244. The exchange digital asset vaults 3238
can store a plurality of digital asset wallets, which may be pooled
exchange customer wallets 3240 with associated digital asset
addresses. In embodiments, the exchange may have a single partner
bank 3242 with a pooled exchange customer fiat account 3244. Such
an account may be associated with insurance protection. In
embodiments, the exchange may have a SVCoin system 3246. Such a
system may allow users to purchase SVCoin tokens using fiat
currency and/or digital assets and/or to redeem digital assets in
the form of SVCoin tokens, and/or to redeem SVCoin tokens for fiat
currency. SVCoin system 3246 may also be used to generate new
SVCoin tokens, and cancel redeem SVCoin tokens. SVCoin system 3246
is operatively connected to an SVCoin database that maintains a log
of SVCoin tokens. In embodiments, the SVCoin database may be
maintained as part of the digital asset network (e.g., the Bitcoin
Network, the Ethereum Network, to name a few).
[0577] The exchange may employ an electronic ledger system to track
customer digital assets and/or customer fiat holdings. Such a
system may allow rapid electronic transactions among exchange
customers and/or between exchange customers and the exchange itself
using its own digital asset and fiat holdings or those of its
sponsor or owner. In embodiments, the electronic ledger system may
facilitate rapid computer-based automated trading, which may
comprise use by one or more computer systems of a trading API
provided by the exchange. The electronic ledger system may also be
used in conjunction with cold storage digital asset security
systems by the exchange. Fiat (e.g., USD) and digital assets (e.g.,
bitcoin or ether) can be electronically credited and/or
electronically debited from respective (e.g., fiat and digital
asset) electronic ledgers. Clearing of transactions may be recorded
nearly instantaneously on the electronic ledgers. Deposits of fiat
with the exchange and withdrawals from the exchange may be recorded
on the electronic fiat ledger, while deposits and withdrawals of
digital assets may be recorded on the electronic digital asset
ledger. Electronic ledgers may be maintained using one or more
computers operated by the exchange, its sponsor and/or agent, and
stored on non-transitory computer-readable memory operatively
connected to such one or more computers. In embodiments, electronic
ledgers can be in the form of a database.
[0578] A digital asset exchange computer system can include one or
more software modules programmed with computer-readable electronic
instructions to perform one or more operations associated with the
exchange. Each module can be stored on non-transitory
computer-readable memory operatively connected to such one or more
computers. An exchange may have a user on-boarding module to
register users with the exchange and/or create accounts for new
and/or existing exchange users. The exchange may employ systems and
methods to ensure that the identity of exchange customers is
verified and/or the destination of fiat currency and/or digital
assets is known.
[0579] FIG. 22A is another schematic diagram illustrating entities
associated with a digital asset exchange in an exemplary embodiment
of the present invention. Each entity may operate one or more
computer systems. Computer systems may be connected directly or
indirectly, such as through a data network. Entities associated
with a digital asset exchange can include the exchange, an exchange
computer system 3230, customer digital asset wallets at associated
digital asset addresses 3222 (e.g., bitcoin wallets, ether wallets,
to name a few), customer bank(s) 3224 having customer fiat bank
account(s) 3226, a digital asset network ledger 3228 (e.g., the
Bitcoin blockchain, the Ethereum blockchain, to name a few), a
digital asset network (e.g., the Bitcoin network), one or more
exchange customers using one or more customer user devices 3232, an
exchange digital asset electronic ledger 3234, one or more exchange
digital asset vaults 3238, an exchange fiat electronic ledger 3236,
and one or more exchange partner banks 3242, which can have
exchange pooled customer fiat accounts 3244. The exchange digital
asset vaults 3238 can store a plurality of digital asset wallets,
which may be pooled exchange customer wallets 3240 with associated
digital asset addresses. In embodiments, the exchange may have a
single partner bank 3242 with a pooled exchange customer fiat
account 3244. Such an account may be associated with insurance
protection.
[0580] The exchange may employ an electronic ledger system to track
customer digital assets and/or customer fiat holdings. Such a
system may allow rapid electronic transactions among exchange
customers and/or between exchange customers and the exchange itself
using its own digital asset and fiat holdings or those of its
sponsor or owner. In embodiments, the electronic ledger system may
facilitate rapid computer-based automated trading, which may
comprise use by one or more computer systems of a trading API
provided by the exchange. The electronic ledger system may also be
used in conjunction with cold storage digital asset security
systems by the exchange. Fiat (e.g., USD) and digital assets (e.g.,
bitcoin or ether) can be electronically credited and/or
electronically debited from respective (e.g., fiat and digital
asset) electronic ledgers. Clearing of transactions may be recorded
nearly instantaneously on the electronic ledgers. Deposits of fiat
with the exchange and withdrawals from the exchange may be recorded
on the electronic fiat ledger, while deposits and withdrawals of
digital assets may be recorded on the electronic digital asset
ledger. Electronic ledgers may be maintained using one or more
computers operated by the exchange, its sponsor and/or agent, and
stored on non-transitory computer-readable memory operatively
connected to such one or more computers. In embodiments, electronic
ledgers can be in the form of a database.
[0581] A digital asset exchange computer system can include one or
more software modules programmed with computer-readable electronic
instructions to perform one or more operations associated with the
exchange. Each module can be stored on non-transitory
computer-readable memory operatively connected to such one or more
computers. An exchange may have a user on-boarding module to
register users with the exchange and/or create accounts for new
and/or existing exchange users. The exchange may employ systems and
methods to ensure that the identity of exchange customers is
verified and/or the destination of fiat currency and/or digital
assets is known. Accordingly, the exchange may require new exchange
customers to provide valid (e.g., complying with certain types,
such as a driver's license or passport, or complying with certain
characteristics) photo identification, a current address, a current
bill, such as a utility bill, biometric information (e.g., a
fingerprint or hand scan), and/or bank account information. A user
on-boarding module can include back-end computer processes to
verify and store user data as well as a front-end user interface by
which a user can provide information to the exchange, select
options, and/or receive information (e.g., through a display). The
user on-boarding module can provide the front-end interface to one
or more user devices and/or platforms, such as a computer, mobile
phone (e.g., running an exchange-related mobile application),
and/or digital asset kiosk, to name a few.
[0582] FIG. 22B shows another schematic diagram illustrating
entities associated with a digital asset exchange in an exemplary
embodiment of the present invention. In addition to the
participants described with respect to FIG. 22A, a digital asset
exchange may communicate with an authenticator computer system 3246
(to authenticate users, e.g., using multi-factor authentication
and/or comparisons to databases of flagged users, to name a few),
an index computer system 3248 (e.g., for generating and/or
providing a digital asset index, which may be a price index),
and/or a market maker computer system 3250. A market maker may be
an exchange user that provides liquidity for the exchange, by
purchasing or selling digital assets.
[0583] In embodiments, an exchange computer system may calculate
different fees for a market maker. The fee calculation may vary
with market conditions, such as price, digital asset supply (e.g.,
sell orders), and digital asset demand (e.g., buy orders). In
embodiments, transaction fees charged by an exchange may be
different for purchase and sale transactions. Fees may be based
upon a user's identity, a user's transaction history, the quantity
of digital assets and/or fiat currency associated with a user
account, a rate schedule associated with a particular account or
account type (e.g., there could be different rates for
institutional or foreign users), time of day, and/or whether the
user is operating as a market maker or a market taker for a given
transaction, to name a few.
[0584] FIGS. 5A-B are schematic diagrams of exemplary exchange
computer systems in accordance with exemplary embodiments of the
present invention. FIG. 5A shows hardware, data, and software
modules, which may run on one or more computers. FIG. 5B shows an
exemplary distributed architecture for the exchange computer
system.
[0585] As shown in FIG. 5A, an exchange computer system 3230 can
include one or more processors 5102, a communication portal 5104
(e.g., for sending and/or receiving data), a display device 5106,
and/or an input device 5108. The exchange computer system 3230 can
also include non-transitory computer-readable memory with one or
more database and data stored thereon. Data can include user
identification data 5110 (e.g. know your customer data obtained
during the user onboarding process), user account authentication
data 5112 (e.g., login credentials, multi-factor authentication
data, and/or anti-money laundering verifications), account
activities logs 5114, electronic ledger data 5116, fiat account
balance data 5118,digital wallet balance data 5120, and/or SVCoin
data 5136, to name a few. One or more software modules may be
stored in the memory and running or configured to run on the one or
more processors. Such modules can include a web server module 5122,
authenticator module 5124, risk management module 5126, matching
engine module 5128, electronic ledger module 5130, digital wallet
module 5132, fiat account module 5134 and/or SVCoin module 5138, to
name a few. The processes performed by such modules, the data
produced thereby and/or the data accessed thereby are described
herein.
[0586] A matching engine 5128 may apply a continuous order book
price time priority matching algorithm. In embodiments, matching
engine 5128 may apply option points at low and/or high frequencies.
In embodiments, other matching engines may be included, such as a
block trade matching engine (not shown), an auction matching engine
(not shown), to name a few.
[0587] As shown in FIG. 5B an exchange computer system can include
a web server 5152, an authenticator computer system 5154, a
matching engine computer system 5156, an electronic ledger computer
system 5158, a risk management computer system 5160, a digital
wallet computer system 5162, a fiat account computer system 5164,
and/or a SV Coin Computer System 5166. The exchange computer system
3230 may communicate with one or more external computer systems,
such as bank computer systems, index computer systems, user
computer system (e.g., institutional or individual users), and/or
user electronic devices, to name a few. Each computer system may
comprise one or more computers and/or one or more processors, a
communication portal, display devices, and/or input devices, to
name a few.
[0588] A web server 5152 may provide display data to one or more
user device 102, e.g., user device 102-1. Display data may comprise
website content (e.g., HTML, JavaScript, and/or other data from
which a user device can generate and/or render one or more
webpages) and/or application content, such as mobile application
content, to be used in generating or providing display content for
one or more software application. In embodiments, the web server
5152 may authenticate a user account by verifying a received
username and password combination. In embodiments, other
authentication processes may also be used.
[0589] An authenticator computer system 5154 may perform
authentication of user login credentials, multi-factor
authentication, and/or compare users against databases, such as
government databases, for compliance with anti-money laundering
laws and/or regulations, to name a few.
[0590] A matching engine computer system 5156 may match buy
(purchase) orders with sell orders, receive orders, and/or update
an electronic order book, to name a few.
[0591] An electronic ledger computer system 5158 may track and/or
store account balances, update account balances, compute account
balances, report account balances, and/or place holds on account
funds while transactions are in progress (e.g., set an account hold
indicator), to name a few.
[0592] A risk management computer system 5160 may perform processes
to detect fraudulent transactions and/or security breaches, to name
a few. Such a sub-system may monitor access data describing access
of the exchange (e.g., IP addresses, accounts, times of access, to
name a few), monitor trading data, analyze trading data, determine
patterns, determine anomalies, and/or determine violations of
pre-programmed security rules, to name a few.
[0593] A digital wallet computer system 5162 may generate digital
wallets with associated digital asset addresses, generate
instructions for digital wallet key storage and/or retrieval,
allocate digital assets among digital wallets, track digital
assets, store digital asset, and/or transfer digital assets, to
name a few.
[0594] The digital wallets may include both hot wallets and cold
wallets. In embodiments, sufficient digital assets will be stored
in one or more hot wallets to allow for liquidity. The amount of
digital assets stored in the one or more hot wallets may be
determined based on historical averages of trading on the exchange.
In embodiments, remaining digital assets will preferably be held in
cold wallets. A more detailed discussion of hot wallets and cold
wallets is presented in U.S. Pat. No. 9,892,460 issued Feb. 13,
2018 entitled SYSTEMS, METHODS, AND PROGRAM PRODUCTS FOR OPERATING
EXCHANGE TRADED PRODUCTS HOLDING DIGITAL MATH-BASED ASSETS, the
entire content of which is incorporated herein.
[0595] A fiat account computer system 5164 may manage omnibus or
pooled accounts for holding customer funds. The fiat account
computer system may process receipts of funds, e.g., from a bank,
via a wire transfer, via a credit card or ACH transfer, and/or via
check, to name a few. Accordingly, the fiat account computer system
may communicate with one or more external systems, such as a bank
computer system. In embodiments, the fiat account computer system
may process withdrawals. In embodiments, the omnibus or pooled
accounts for holding fiat are maintained in a bank or other
institution such that these accounts are eligible for insurance
under the Federal Deposit Insurance Corporation (FDIC). In order to
qualify for FDIC insurance, an account must typically be associated
with specific user identification information, e.g., a user name,
address and social security number, by way of example, to name a
few. Accordingly, in embodiments, fiat accounts may be associated
with individuals who are positively identified. In such
embodiments, SVCoin holders may be required to provide the
identification information discussed above prior to purchasing
SVCoins. Further, the SVCoin issuer will maintain a database
including this information for each SVCoin holder. In embodiments,
the fiat may be invested in federally insured interest bearing bank
accounts, treasure bills, bonds (such as high quality bonds), CD's,
money market mutual funds, repos or other financial instruments
which offer a return and provide sufficient stability, to name a
few.
[0596] A SVCoin computer system 5166 may manage purchases of SVCoin
tokens using fiat currency and/or digital assets and/or redemption
of digital assets in the form of SVCoin tokens, and/or redemption
of SVCoin tokens for fiat currency. SVCoin computer system 5166 may
also generate new SVCoin tokens and cancel redeem SVCoin tokens.
SVCoin computer system 5166 is operatively connected to an SVCoin
database 5136 that maintains a log of SVCoin tokens. In
embodiments, the SVCoin database 5136 is maintained by the use of
smart contract code associated with a Contract Address on the
digital asset blockchain though the digital asset network.
[0597] Referring to the fiat account funding process shown in FIG.
6, In step S4720 the exchange computer system may receive fiat
funding account information. Such information can include a bank
account number (e.g., a routing number), a bank name, an account
type, and/or an account holder's name, to name a few. In step
S4722, the exchange computer system may perform one or more
validation transactions using the fiat funding account. Such
transactions may comprise small deposits into the fiat funding
account. In step S4724, the exchange computer system may receive
validation transaction information, which may include a transaction
amount, date, and/or time. In step S4726, the exchange computer
system may electronically authorize use of the fiat funding account
and/or request a funding transfer. Accordingly, the exchange
computer system may provide an electronic notification, e.g., via
email, via a website, and/or via a mobile phone application (e.g.,
via a push notification), to name a few, that the fiat funding
account is authorized for use with the exchange. A customer may
electronically initiate a transaction, e.g., through an
exchange-provided user interface or user electronic device
operatively connected to the exchange or an application programming
interface (API), to name a few, to transfer funds to the exchange.
In step S4728, the exchange computer system may receive an
electronic notification indicating that funds were received, e.g.,
in an exchange bank account at a partner bank, from the customer
fiat funding account. In step S4730, the exchange computer system
can update an exchange customer account with the received funds.
Updating an exchange customer account can comprise electronically
updating a fiat electronic ledger stored one or more computer
readable media operatively connected to the exchange computer
system to reflect the received funds and/or updating a display of
the amount of funds in the account or a data ledger on a user
computer device or on a printed and/or digitally transmitted
receipt provided to the user and/or a user device.
[0598] Referring to the digital asset account funding process shown
in FIG. 6, In step S4734, the exchange computer system can receive
an initial transfer of digital assets. In step S4736, the exchange
computer system can receive a confirmation of clearance of the
digital asset transfer. In step S4738, the exchange computer system
can update an exchange customer account with the received digital
assets. Updating an exchange customer account can include making an
electronic entry in an exchange digital asset electronic ledger
and/or providing a notification that the digital assets are
received.
[0599] FIG. 7A is an exemplary schematic diagram of an exchange,
and FIG. 7B is a corresponding flow chart of a process for digital
asset exchange customer account fiat funding via an
exchange-initiated request, such as ACH in accordance with
exemplary embodiments of the present invention. An exchange
computer system 4810 can interface with a customer digital asset
wallet 4802, a bank 4804 with a customer fiat bank account 4806, an
exchange partner bank 4822 with an exchange pooled customer fiat
account 4824, a network digital asset ledger 4808, and/or a
customer's user device 4812, to name a few. In addition to the
exchange computer system 4810, the exchange can include an exchange
digital asset electronic ledger 4814, an exchange fiat electronic
ledger 4816, and an exchange digital asset vault 4818 with exchange
pooled customer digital asset wallets 4820 with associated digital
asset addresses. Any of these entities or components may
communicate directly and/or indirectly, e.g., through a data
network, such as the Internet. In embodiments, encryption and/or
other security protocols may be used. These entities and components
are further described with respect to FIG. 4A.
[0600] Referring to FIG. 7B, In step S4802 the exchange computer
system can receive, e.g., from a user device, user access
credentials. In step S4804, the exchange computer system can
authenticate the user, such as by verifying the received access
credentials. In step S4806, the exchange computer system may
provide to a customer user device a fiat funding interface. In step
S4808, the exchange computer system may receive from the user
device user selections for a funding source and/or funding method.
The funding source may identify a bank account or other fiat
account. The funding method may identify ACH transfer or wire
transfer, to name a few. In step S4810, the exchange computer
system can receive from the user device a funding amount value to
transfer to an exchange account associated with the user. In some
embodiments, step S4808 and step S4810 may be a single step or may
occur substantially simultaneously. Accordingly, the exchange
computer system may receive from a user electronic device a user
electronic request comprising a funding amount and a funding
method. In embodiments, the funding method may be an ACH transfer
and the request further identifies a verified user bank
account.
[0601] In step S4812, the exchange computer system can transmit a
fund transfer request to a bank where the customer has a fiat bank
account. Accordingly, the exchange computer system may transmit to
an exchange partner bank an electronic funding request comprising
the funding amount and the user bank account identifier.
[0602] In step S4814, the exchange computer system can update an
exchange fiat electronic ledger with the funding transaction
information. In step S4816, the exchange computer system can
receive an electronic indication that the funding amount was
transferred from the customer's fiat bank account to an exchange
fiat account, e.g., at a partner bank. In step S4818, the exchange
computer system can monitor the exchange fiat account to determine
the availability of funds in an exchange account associated with
the user. In embodiments, the exchange computer system may generate
and/or provide an electronic notification to one or more user
devices associated with a user account that funds are available for
use on the exchange. In embodiments, the notification may indicate
a current balance of a user account (e.g., in fiat currency and/or
digital asset quantities).
[0603] FIG. 7C is an exemplary schematic diagram of an exchange,
and FIG. 7D is a corresponding flow chart of a process for digital
asset exchange customer account fiat funding via a
customer-initiated request, such as a wire transfer, in accordance
with exemplary embodiments of the present invention. The components
and entities associated with an exchange that are shown in FIG. 7C
are described with respect to FIG. 4A.
[0604] FIG. 7D is a flow chart showing an exemplary process for
digital asset exchange customer account fiat funding. In step
S4852, an exchange computer system can receive user access
credentials. In step S4854, the exchange computer system can
authenticate the user by verifying the received access credentials.
Verifying the access credentials can comprise comparing the
credentials to a secure credentials database. In step S4856, the
exchange computer system can provide to a customer user device a
fiat funding interface. In step S4858, the exchange computer system
can receive from the customer user device, user selections for a
funding source and/or funding method. The funding method may be a
customer-initiated method, such as a wire transfer. In step S4860,
the exchange computer system can receive a funding amount value to
transfer to an exchange account associated with the user. In step
S4862, the exchange computer system can provide to the customer
user device fund transfer instruction, e.g., wire instructions. In
step S4864, the exchange computer system may receive an electronic
indication of a customer-initiated fund transfer from a customer
fiat bank account a customer bank to an exchange fiat account at an
exchange partner bank according to the fund transfer instructions.
In embodiments, step S4864 may be skipped. In step S4866, the
exchange computer system may receive an indication that the funding
amount was transferred from the customer's fiat bank account to the
exchange fiat account. In step S4868, the exchange computer system
can update an exchange fiat electronic ledger with the funding
transaction information, which may include an amount value,
customer account ID, transaction date and/or time, to name a few.
In step S4870, the exchange computer system can monitor the
exchange fiat account to determine the availability of funds in an
exchange account associated with the user. In step S4872, the
exchange computer system can provide an electronic notification to
one or more customer user devices that funds are available for use
on the exchange.
[0605] FIG. 7E is a flow chart showing another exemplary process
for digital asset exchange customer account fiat funding. In step
S4852', an exchange computer system can receive user access
credentials. In step S4854', the exchange computer system can
authenticate the user by verifying the received access credentials.
Verifying the access credentials can comprise comparing the
credentials to a secure credentials database. In step S4856', the
exchange computer system can provide to a customer user device a
fiat funding interface. In step S4857, the exchange computer system
can receive a user electronic request comprising a funding amount
and a funding method (e.g., a wire transfer). In step S4859, the
exchange computer system can provide to the customer user device,
an electronic message and/or display data comprising wire transfer
instructions. In step S4861, the exchange computer system can set a
pending transfer indicator and/or initiate a funds receipt
monitoring process. In step S4863, the exchange computer system can
receive an electronic indication that funds were received via wire
transfer at an exchange fiat account at an exchange partner bank.
In step S4865, the exchange computer system can verify that the
received funds were transferred from the authorized customer's fiat
bank account to the exchange fiat account. In step S4868', the
exchange computer system can update an exchange fiat electronic
ledger with the funding transaction information, which may include
an amount value, customer account ID, transaction date and/or time,
to name a few. In step S4870', the exchange computer system can
monitor the exchange fiat account to determine the availability of
funds in an exchange account associated with the user. In step
S4872', the exchange computer system can provide an electronic
notification to one or more customer user devices that funds are
available for use on the exchange.
[0606] FIG. 8A is an exemplary schematic diagram of an exchange,
and FIG. 8B is a corresponding flow chart of a process for digital
asset exchange account digital asset withdrawal in accordance with
exemplary embodiments of the present invention. The components and
entities associated with an exchange that are shown in FIG. 8A are
described herein with respect to FIG. 4A.
[0607] Referring to FIG. 8B, In step S4902, an exchange computer
system can receive user access credentials. User access credentials
can include any of a username, password, fingerprints, access card
scan (e.g., swipe of a card associated with the exchange and having
a magnetic strip), and/or a pin (e.g., a number provided via SMS,
other text message service, or email for multi-factor
authentication), to name a few. In step S4904, the exchange
computer system can authenticate the user based upon the received
user access credentials. In step S4906, the exchange computer
system may provide to a customer user device a withdrawal
interface. In step S4908, the exchange computer system may receive
from the customer user device user inputs comprising at least a
destination digital asset address, typically associated with a
destination digital wallet and a requested digital asset withdrawal
amount value. In step S4910, the exchange computer system may
verify that a digital asset account associated with the customer
contains sufficient digital assets to cover the requested
withdrawal amount. In embodiments, such verification can comprise
reading a digital asset electronic ledger and/or determining a
customer digital asset balance, e.g., based on summing transactions
recorded on a digital asset electronic ledger. In step S4912, the
exchange computer system may update an exchange digital asset
electronic ledger to reflect the pending withdrawal. In
embodiments, recording an entry in the electronic ledger prior to
the withdrawal may be performed to prevent double spending. In
other embodiments, such a step may be skipped. In step S4914, the
exchange computer system may execute the withdrawal, e.g., by
broadcasting the withdrawal to a digital asset network electronic
ledger, e.g., the Bitcoin Blockchain, the Ethereum Blockchain, to
name a few. In step S4916, the destination wallet may receive an
electronic notification of the receipt of digital assets from the
exchange. In step S4918, the exchange computer system may monitor
the network digital asset ledger to determine whether and/or when
the withdrawal transaction is confirmed. In step S4920, the
exchange computer system may update the digital asset electronic
ledger, e.g., by debiting the withdrawal amount from the customer's
exchange account, to reflect confirmation of the withdrawal
transaction. In step S4922, the exchange computer system may
provide to one or more customer user devices an electronic
notification of the withdrawal. Such a notification can include at
least the customer's new digital asset balance.
[0608] A digital asset exchange can include additional systems,
which may include software modules, for performing various
functions of the exchange. For example, an exchange can include an
account management system, which may comprise a user account
registration system for new users and/or an existing user account
management system. The exchange can include a trading system, which
may comprise an interactive trading interface system, an automated
trading interface system, a trade confirmation notification system,
and/or a trade transaction fee processing system. A fund transfer
system can include a fiat account funding and redemption system, a
digital asset accounting funding and redemption system, and an
account funding and redemption fee processing system. An exchange
can also include a trade settlement system. A customer service
system can include a trade dispute resolution interface system and
a customer account management assistance system. A customer
reporting system can include a gain an loss reporting system and a
transaction history system. A fraud analysis system can monitor
transactions to detect fraudulent and/or unauthorized transactions.
The exchange can also include a SVCoin system, which may comprise a
purchase system, redemption system, and a dividend payment system.
In a preferred embodiment, a SVCoin system is included to allow
users to purchase and redeem stable value coins using fiat currency
and/or other digital assets.
Exchange Digital Asset Storage Structure
[0609] Deposited customer fiat may be held in a pooled fiat account
maintained in a partner bank. Meanwhile, digital assets held by the
exchange may be maintained in pooled digital addresses associated
with pooled digital wallets. The exchange may store digital assets
using any of the security and/or storage systems and methods
discussed herein. The exchange can employ any combination of
varying levels of secure storage for its wallets. For example,
portions of digital assets held by the exchange may be maintained
in cold storage with neither the wallet's private nor public keys
ever having been exposed to a digital asset network or other
external network, such as the Internet. Other digital assets may be
stored in air-gapped hot wallets, which may be wallets generated
off-line with transactions generated off-line, e.g., on an isolated
computer, and transferred to a networked computer via a temporary
physical connection or manual transfer. Other digital assets may be
maintained in hot wallets, e.g., to satisfy withdrawals from the
exchange. The exchange may determine the amount of assets to hold
in hot wallets, which may be based on historical exchange activity
and/or anticipated need. A hot wallet liquidity module may analyze
and predict the amount of assets per wallet and/or during a time
period required to meet anticipated need and may also initiate
transfers of assets to or from hot wallets to maintain desired
levels. For example, a hot wallet liquidity module could determine
that it is desirable to maintain digital assets in certain defined
amounts (e.g., 0.5 bitcoin), and/or certain defined fiat amounts
(e.g., $100 worth of bitcoin) and/or of certain defined quantities
sufficient to cover transactions anticipated during a defined
period (e.g., the day's transaction). In embodiments, initiating an
electronic transfer may comprise electronically generating and
providing an electronic notification to devices associated with one
or more exchange administrators of a need to transfer assets and/or
an amount of assets to transfer. The exchange may designate one or
more wallets for receiving incoming digital assets only. For
example, the exchange may employ a single digital wallet for each
receipt of digital assets, e.g., from exchange users. The receiving
wallet may be destroyed after the received assets are transferred
to one or more other wallets.
[0610] The exchange may employ any of a number of different
exchange digital wallet systems. As discussed herein, the exchange
may operate a pooled or omnibus digital wallet system, e.g., as
part of a centralized exchange system. The pooled system may use an
electronic ledger to track digital asset ownership for each
exchange customer. Customers may transfer digital assets from their
own digital wallets to an exchange address in order to fund their
digital asset account on the exchange. The ledger can track (e.g.,
record) such funding events, as well as withdrawal events.
Transfers of digital assets among customers can also be accounted
for using the ledger. With a pooled wallet system, internal
transactions on the exchange (e.g., transactions that do not entail
transferring funds to or from the exchange or exchange wallets but
rather transactions between exchange wallets) can be settled
without delay, since the transfer can be logged through electronic
ledger updates and does not have to otherwise be processed by a
digital asset network.
[0611] In another embodiment, the exchange digital wallet system
may comprise exchange operated wallets for each exchange customer.
These exchange operated wallets may be maintained in trust by the
exchange for each customer as associated digital asset addresses.
Transactions may be processed by the digital asset network, e.g.,
the Bitcoin network, the Ethereum network, to name a few. The keys
to each customer wallet may be held by the customer and/or by the
exchange. Transactions may be settled via the digital asset network
in real-time (with any corresponding confirmation period) as they
occur, or transactions may be settled in a batch, which may entail
broadcasting a plurality of transactions to the network at a
particular time or periodically throughout a day.
[0612] In another embodiment of an exchange digital wallet system,
the exchange customers may own and/or manage their own wallets,
e.g., as part of a decentralized exchange system. The exchange
would not hold any customer digital assets, and customers would
hold the private keys to their wallets with associated digital
asset addresses. The exchange may match customers, as described
herein, so that a digital asset seller can transfer digital assets
from the seller's digital wallet to a digital wallet corresponding
to a digital asset buyer.
[0613] In embodiments, the digital wallet may be a custodial
digital wallet. The custodial digital wallet may be segregated,
that is, unique to a particular customer or commingled, including
digital assets of multiple customers. In such an embodiment, the
custodian holds digital assets in the custodial wallet for the
benefit of its customers. The custodian would hold the private key
or private keys/key segments to each custodial wallet whether it be
segregated or commingled. Transactions may be made between
different custodial wallets or between custodial wallets and
exchange customer wallets in the manner described above.
Centralized Digital Asset Exchange
[0614] In embodiments, the exchange may hold customer fiat currency
and/or digital assets in centralized, pooled accounts or wallets.
The exchange may maintain an electronic ledger to record
transactions among users of the exchange. Separate electronic fiat
account ledgers and electronic digital asset ledgers may be
maintained. Maintaining a ledger may involve electronically
updating the ledger to reflect pending transactions and/or
completed transactions, which may involve debiting assets from a
user's account and/or crediting assets to a user's account.
Broadcast to a digital asset network and confirmation from a
digital asset network may not be performed for transactions within
the exchange, e.g., transactions between a digital asset seller
selling digital assets that are stored by the exchange and a buyer
paying with fiat currency that is held in an exchange bank account,
such as a pooled account.
[0615] In embodiments, for both a decentralized and a centralized
exchange the exchange may provide the ability for customers to
purchase digital assets from the exchange and/or sell digital
assets to the exchange such that the exchange operator or owner is
the counterparty to the transaction. Transaction amount limits may
be placed on such transactions and/or additional fees may be
charged. In addition, in embodiments, the exchange may provide a
dashboard interface for users (such as registered users) to
purchase SVCoins using fiat currency and/or digital assets and/or
to redeem digital assets in the form of SVCoins. In embodiments,
the dashboard interface for the exchange may also allow users to
redeem SVCoins for fiat currency. Since SVCoins are pegged to a
fixed notional value of fiat currency, when SVCoins are purchased
an equal amount of fiat will be set aside by the exchange as a
reserve for when the SVCoins are redeemed. Similarly, when SVCoins
are redeemed, payment for such redemption shall come from reserves
set aside for such redemption.
Exchange Operations Systems
[0616] In embodiments, a digital asset exchange may require users
to open designated accounts associated with the user in order to
participate in the exchange. Each user may have a digital
math-based asset account to record and maintain such user's digital
math-based assets and a fiat account to record and maintain such
user's fiat assets. In embodiments, the fiat assets recorded in the
fiat account may be U.S. Dollars ("USD") held in one or more
omnibus bank accounts with one or more FDIC-insured depository
institutions or banks. In embodiments, a digital math-based asset
computer system of a digital asset exchange may record in an
electronic ledger information associated with a user account, such
as digital math-based asset purchase orders, digital math-based
asset sell orders, digital math-based asset purchase offers,
digital math-based asset sell offers. In embodiments, digital
math-based asset purchase offers and digital math-based asset sell
offers may be converted into digital math-based asset purchase
orders and digital math-based asset sell orders, respectively,
according to a user's instructions, if certain user-specified
factors are met (e.g., digital math-based assets are within a given
price, quantity, period of time, to name a few). In embodiments,
when the digital math-based asset computer system matches an
electronic digital math-based asset purchase order with an
electronic digital math-based asset sell order, the digital
math-based asset computer system may record the trade in an
electronic ledger, effectively transferring ownership of the
seller's traded digital math-based assets to the buyer, and
ownership of the related purchase price in fiat currency from the
buyer to the seller. In embodiments, the changes in a user's
ownership of digital math-based assets and fiat currency recorded
in the electronic ledger are reflected in a user's digital
math-based asset account and fiat account.
[0617] In embodiments, a digital asset exchange may accept payment
methods (e.g., credit card transactions; Automated Clearing House
(ACH) debits, wire transfers, digital asset transactions, to name a
few) for purchases of digital assets.
[0618] In embodiments, a digital asset exchange may hold digital
math-based assets and/or fiat currency in trust for users. Fiat
currency may be maintained in accounts with a state or federally
chartered bank and may be eligible for FDIC insurance, subject to
compliance with applicable federal regulation. In embodiments, a
digital asset exchange may also operate a digital math-based asset
storage system, in which users may deposit digital math-based
assets. In embodiments, fiat currency may be transmitted to a
digital asset exchange's omnibus account. In embodiments, the
exchange may transmit fiat currency back to a user upon receiving a
request from a user.
[0619] In embodiments, a digital asset exchange may comply with
relevant laws and regulations whereby the exchange may operate in a
highly regulated banking environment and permit necessary
supervision by relevant legal authorities. In embodiments, a
digital asset exchange may comply with rules and regulations
promulgated by a self-regulatory organization. In embodiments, when
a user commences an electronic digital math-based asset purchase
order to acquire digital math-based assets, the user may either
have fiat currency in an associated user account or the buyer may
send fiat currency to the digital asset exchange's omnibus account
at the applicable bank. In embodiments, when a seller commences an
electronic digital math-based asset sell order to sell digital
math-based assets, the seller may either have digital math-based
assets in an associated user account or may send digital math-based
assets to a digital math-based asset account. In embodiments, the
seller may send digital math-based assets to one or more of digital
wallets held by the exchange. In embodiments, exchange transactions
may only be completed after the digital math-based asset computer
system verifies that the digital math-based asset accounts and fiat
accounts associated with the users involved in the transaction at
least equal the quantities required by the transaction. In
embodiments, the exchange may permit trading twenty-four hours a
day, seven days a week. In embodiments, the exchange may shut down
for scheduled and/or unscheduled maintenance periods. In
embodiments, the exchange may prohibit users from transferring fiat
currency outside of normal business hours, in order to comply with
applicable laws and regulations. In embodiments, the exchange may
allow users to deposit and withdraw digital math-based assets
outside of normal business hours. In embodiments, the exchange may
permit users to sell digital math-based assets for fiat currency or
buy digital math-based assets with fiat currency if the user holds
sufficient fiat currency in its associated account prior to
initiating the transaction.
Exchange-Based Stable Value Coin to Fiat Portal
[0620] In embodiments, a digital asset exchange (such as a
regulated exchange) can be used to exchange SVCoin for fiat and
fiat for SVCoin. Since SVCoin is a stable value token, each token
will be pegged to a stable value of fiat (e.g., 1 SVCoin=1 USD or 1
SVCoin=1 EUR, to name a few). In embodiments, when fiat is provided
to a digital asset exchange to purchase SVCoin, a sufficient amount
of fiat to cover the notional value of the SVCoin will be set aside
and held until the SVCoin is redeemed. Similarly, when SVCoin is
redeemed the corresponding amount of fiat associated with the
notional value of the SVCoin will be taken from such reserves to
cover the redemption. In embodiments, each time SVCoins are
purchased, redeemed and/or traded, transaction fees may be charged
by the SVCoin issuer, and/or others involved in the transaction,
such as miners on the digital asset network. Such transaction fees
may be charged in fiat, SVCoin and/or other digital assets (e.g.,
Gas, bitcoin, ether, to name a few).
[0621] An example of a SVCoin could be Gemini Dollar. In
embodiments, when fiat is provided to a digital asset exchange to
purchase SVCoin, a sufficient amount of fiat to cover the notional
value of the SVCoin will be set aside and held until the SVCoin is
redeemed. Similarly, when SVCoin is redeemed the corresponding
amount of fiat associated with the notional value of the SVCoin
will be taken from such reserves to cover the redemption.
[0622] In embodiments, each time SVCoins are purchased, redeemed
and/or traded, transaction fees may be charged by the SVCoin
issuer, and/or others involved in the transaction, such as miners
on the digital asset network. Such transaction fees may be charged
in fiat, SVCoin and/or other digital assets (e.g, Gas, bitcoin,
ether, to name a few). For example, a purchaser may pay $1.01 USD
for 1 SVcoin (that has a redemption value of $1.00 USD).
[0623] In embodiments, the SVCoin issuer may provide a discount to
a purchaser of SVCoin, which may be reflected in fiat, SVCoin
and/or other digital assets (e.g., Gas, bitcoin, ether, to name a
few). For example, a purchaser may pay $0.99 USD for 1 SVCoin (that
has a redemption value of $1.00 USD).
[0624] In embodiments, transaction fees and/or discounts can be
incurred and/or paid at the time of transfer or at another
time.
[0625] In embodiments, the SVCoin may be pegged to another stable
value token. In embodiments, the SVCoin may be pegged to the value
of another asset, other than fiat. In embodiments, the SVCoin may
be pegged to the value of a security, for example, a certificate of
stock in a particular company. In embodiments, a purchaser of the
SVCoin may deposit or otherwise provide to the digital asset
exchange, a share of stock and will receive an SVCoin token in
return. In embodiments, the digital asset exchange will hold the
share of stock, in a custodial account, for example, until it is
redeemed. In embodiments, rather than deposit a share of stock, a
purchaser of SVCoin may deposit a sum of fiat, or other assets,
sufficient to purchase a share of stock. In embodiments, the
digital asset exchange may acquire a share of stock on the market
using the assets deposited by the purchaser and then hold the share
of stock until the SVCoin is redeemed.
[0626] In embodiments, the SVCoin may be pegged to the value of a
commodity. In embodiments, a purchaser of SVCoin may deposit a sum
of fiat, or other assets, sufficient to purchase a quantity of a
commodity. In embodiments, the digital asset exchange may hold an
amount of the commodity, in a custodial account, for example, until
the SVCoin is redeemed. In embodiments, the digital asset exchange
may acquire the quantity of the commodity on the market using the
assets deposited by the purchaser and then hold the commodity until
the SVCoin is redeemed.
[0627] In embodiments, the SVCoin may be pegged to a derivative
product of a stock, commodity and/or another digital asset to name
a few.
[0628] In embodiments, when a user (such as a registered user of a
regulated digital asset exchange) commences a purchase order to
acquire SVCoin for fiat, the user may have fiat currency in an
associated user account. Alternatively, the user may send fiat
currency to the exchange's account, such as an omnibus account, at
the applicable bank. In embodiments, when a seller sells SVCoin,
the seller may have the SVCoin in an associated user account or may
send SVCoin to a digital asset account. Specifically, the seller
may send SVCoin to one or more of digital asset addressed,
typically associated with digital wallets held by the exchange. In
embodiments, exchange transactions may only be completed after the
verification that the digital asset accounts and fiat accounts
associated with the users involved in the transaction at least
equal the quantities of each required by the transaction.
[0629] In embodiments, registered users of a digital asset exchange
system, such as Gemini, may purchase and/or redeem SVCoins for fiat
and/or other digital assets though one or more digital asset
dashboard interfaces. In embodiments, the one or more digital asset
dashboard interfaces may include: (i) a dashboard fiat interface
which allows registered users to deposit and/or withdrawal fiat
with the digital asset exchange; (ii) a dashboard digital asset
interface which allows registered users to deposit and/or
withdrawal digital assets with the digital asset exchange system;
(iii) a dashboard SVCoin interface which allows registered users to
purchase and/or redeem SVCoins with the digital asset exchange
system; and (iv) a dashboard Security Token interface which allow
Security Token issuers to provide instructions to transfer SVCoins
to Security Token holders. Each of these dashboard interfaces will
now be described in turn.
[0630] FIGS. 11A-1-4 illustrates an exemplary embodiment of a
dashboard fiat interface which allows registered users to deposit
and/or withdraw fiat with the digital asset exchange.
[0631] FIG. 11A-1 illustrates an exemplary embodiment of the
dashboard fiat interface as used for deposit of fiat. As
illustrated, the user has the option to make a transfer from a bank
to the exchange by indicating an amount of fiat 1102 (e.g., US
dollars) to be transferred from a funding source 1100 (e.g., a bank
account).
[0632] FIG. 11A-2 illustrates an exemplary embodiment of the
dashboard fiat interface providing an option of a wire transfer. As
in FIG. 11A-1, the user indicates an amount of fiat 1102 to be
transferred from a funding source 1100, such as a bank, to be wired
to the exchange.
[0633] FIG. 11A-3 illustrates the dashboard fiat interface as used
to withdraw fiat from the exchange and deposit it into a
destination (e.g., a bank). In this case, the user provides a
withdrawal amount of fiat 1104 and a destination 1106, such as a
bank account, for the specific fiat.
[0634] Similarly, FIG. 11A-4 illustrates the dashboard fiat
interface as used to withdraw fiat via a wire transfer where the
user enters the withdrawal amount of fiat 1104 and a destination
1106, such as a bank account.
[0635] FIGS. 11B-1-4 illustrates an exemplary embodiment of a
dashboard digital asset interface which allows registered users to
deposit and/or withdrawal digital assets with the digital asset
exchange system.
[0636] FIG. 11B-1 illustrates an exemplary embodiment of the
dashboard fiat interface as used for deposit of digital assets,
specifically bitcoin in this nonlimiting example. As illustrated,
the user enters the current address 1112 of the digital asset
(e.g., bitcoin, ether, etc.).
[0637] FIG. 11B-2 illustrates another exemplary embodiment of the
dashboard fiat interface as used for deposit of digital assets,
specifically ether this nonlimiting example. As illustrated, the
user enters the current address 1112 of the digital asset (ether in
this example.
[0638] FIG. 11B-3 illustrates an exemplary embodiment of the
dashboard fiat interface as used for withdrawal of digital assets,
specifically bitcoin in this nonlimiting example. As illustrated,
the user enters the destination address 1114 for the digital asset
(bitcoin) as well as amount of digital assets 1116 to be
withdrawn.
[0639] FIG. 11B-4 illustrates an exemplary embodiment of the
dashboard fiat interface as used for withdrawal of digital assets,
specifically ether this example. As illustrated, the user enters
the destination address 1114 of the digital asset (ether) as well
as amount of digital assets 1116 to be withdrawn.
[0640] FIGS. 11C-1-2 illustrates an exemplary embodiment of a
dashboard SVCoin interface which allows registered users to
purchase and/or redeem SVCoins with the digital asset exchange
system.
[0641] FIG. 11C-1 illustrates an exemplary embodiment of the
dashboard fiat interface as used to purchase SVCoins using fiat. As
illustrated, the user may enter an amount of fiat (U.S. dollars, in
this example) 1122 to be provided from a source 1124 (e.g., a bank
account) to purchase the SVCoins.
[0642] FIG. 11C-2 illustrates an exemplary embodiment of the
dashboard fiat interface as used to purchase SVCoins using digital
assets (bitcoin in this example). As illustrated, the user may
enter the current address of the digital asset 1126.
[0643] In embodiments, a registered user may purchase SVCoins in
exchange for fiat. Referring to FIG. 9A, in S9902, a registered
user may log in to the dashboard SVCoin interface, such as
illustrated in FIGs.11C1-2.
[0644] In S9904, the user selects the purchase SVCoin option, and
specifies the amount of SVCoins the user seeks to obtain. In
embodiments, the user may be requested to provide a digital asset
address, typically associated with a digital wallet, such as a
digital asset address associated with a blockchain digital asset,
like ether. In embodiments, the amount of SVCoins to be purchased
may be specified by number of SVCoins, or by an amount of fiat.
Since the SVCoins are pegged to the fiat in a stable amount (e.g.,
1 SVCoin=1 USD), the system can automatically convert and display
the requested amount of SVCoin into fiat, or requested amount of
fiat into SVCoin.
[0645] In S9906, the digital asset exchange system will analyze and
verify that the request can be properly processed. In step S9906-a,
the digital asset exchange system, as the SVCoin issuer, may verify
that the user has sufficient fiat currency maintained at the
digital asset exchange to cover the transaction, including a
sufficient amount of fiat to cover the amount of SVCoin being
acquired, as well as any transaction fees that may be charged. If
the user does not have sufficient fiat in the system, the
transaction may be terminated for insufficient funds. In
embodiments, the user may be provided an opportunity to obtain
sufficient funds, by, e.g., selling digital assets maintained by
the user on the digital asset exchange or by making a deposit of
additional fiat. In step S9906-b, the digital asset exchange
system, may also verify that the digital asset address provided is
a valid digital asset address. In step S9908-c, the digital asset
exchange system, may also publish transactions to blockchain.
[0646] In S9908, after the digital asset exchange system has
confirmed that the user has sufficient fiat to cover the
transaction, the digital asset exchange system may initiate the
process of generating the requested SVCoin. In embodiments, where
SVCoins were previously generated, then S9908 may be replaced with
an alternative process S9908' as discussed below.
[0647] Returning to S9908, in S9908-a, the digital asset exchange
system may debit the designated fiat funds from a fiat ledger
associated with the user account, and credit a corresponding amount
of fiat to the SVCoin fiat ledger to be held in trust by the
Exchange.
[0648] In S9908-b, the digital asset exchange system shall generate
the requested SVCoin tokens. As part of this step, or as an
additional step, the digital asset exchange system will update the
SVCoin ledger to reflect the creation of the newly generated
SVCoins and to indicate the digital asset address associated with
these newly generated SVCoins.
[0649] In S9908-c, the digital asset exchange system shall publish
to the blockchain network (e.g., the Ethereum Network) the
transaction to be recorded by the blockchain network. In
embodiments, a transaction fee may be required by, e.g., a miner,
to process and add the requested transaction on the blockchain.
[0650] As noted, when a reserve of SVCoin had been previously
created but not yet distributed by the digital asset exchange
system, S9908' may be implemented instead of S9908. At step
S9908-a', digital asset exchange computer system may debit the
designated fiat funds from a fiat ledger associated with the user
account, and credit a corresponding amount of fiat to the SVCoin
fiat ledger to be held in trust by the Exchange.
[0651] In step S9908-b', the digital asset exchange computer system
may determines an appropriate amount of SVCoin from the reserve to
satisfy the request.
[0652] In step S9908-c', the digital asset exchange computer system
updates the SVCoin ledger to change the address associated with the
portion of the reserve determined in step S9908b' to the address
associated with the user.
[0653] In S9910, the digital asset exchange computer system may
send a message to the registered user, and/or the designated
digital asset address to reflect that the transaction was
successfully processed. In embodiments, such messages may include
information including: (i) digital asset address; (ii) the amount
of tokens generated; and/or (iii) the new balances for the digital
asset address.
[0654] In embodiments, a registered user may redeem SVCoins in
exchange for fiat. Referring to FIG. 9B, in S9952, a registered
user may log in to the dashboard SVCoin interface, such as
illustrated in FIGS. 11C-1 and 11C-2.
[0655] In S9954, the user selects the redeem SVCoin option, and
specifies the amount of SVCoins the user seeks to redeem. In
embodiments, the user may be requested to provide a digital wallet
address, such as a digital wallet address associated with a
blockchain digital asset, like ether. In embodiments, the amount of
SVCoins may be specified by number of SVCoins, or by an amount of
fiat. Since the SVCoins are pegged to the fiat in a stable amount
(e.g., 1 SVCoin=1 USD, or 100 SVCoin=1 USD, to name a few), the
system can automatically convert the requested amount of SVCoin to
fiat, or requested amount of fiat into SVCoin.
[0656] In S9956, the digital asset exchange system will analyze and
verify that the request can be properly processed. In step S9956-a,
the digital asset exchange system, as the SVCoin issuer, may verify
that the user has sufficient SVCoin to cover the transaction as
well as any transaction fees that may be charged. In embodiments,
the digital asset exchange system may perform verification of the
SVCoin balance by checking the token balance of the digital asset
address against the SVCoin Token ledger as maintained by the
digital asset blockchain. For example, a balance for a token issued
based on the Ethereum Network may be checked at www.etherscan.io.
If the user does not have sufficient SVCoin and/or an insufficient
amount for transaction fees and/or provided an invalid digital
asset address, to name a few, the transaction may be
terminated.
[0657] In embodiments, SVCoin transactions may be published and
recorded in a SVCoin token side ledger that is separate from an
underlying blockchain (e.g., the Ethereum Blockchain). Such a side
ledger may be provided using a sidechain, for example, a plasma
chain, which is separate from the underlying digital asset
blockchain that is maintained on the distributed network. In
embodiments, this sidechain is used to record all transactions
involving the SVCoin token and is maintained by the token issuer or
another trusted entity on behalf of the token issuer. These
transactions may then be subsequently published to the underlying
digital asset blockchain periodically or aperiodically such that
all transactions are publicly viewable and confirmable. In
embodiments, with a blockchain supporting shielded transactions,
the transactions in the SVCoin token may potentially be shielded
and only viewable by authorized token holders. In embodiments,
transactions on the sidechain may be consolidated prior to
publication on the digital asset blockchain to increase speed of
processing and reduce transaction costs.
[0658] The use of a sidechain in conjunction with a blockchain can
provide certain technical advantages not otherwise available by
either alone. For example, since all transactions on the sidechain
are inevitably published to the digital asset blockchain, these
transaction records enjoy the same benefit of immutability provided
to all other transactions on the digital asset blockchain. However,
use of a sidechain reduces both transaction costs and transaction
times overall. Recording the transactions on the sidechain first
can be accomplished more rapidly than transactions that are
published directly to the digital asset blockchain, which must be
confirmed prior to being added to the digital asset blockchain. In
embodiments, the sidechain may simply be a database that records
all transactions such that there is no need for miners to verify
each transaction, and thus, no need to pay miners for this service.
In this case, transaction costs are only incurred for the periodic
or aperiodic publication of transfers from the sidechain to the
underlying digital asset blockchain.
[0659] In embodiments, the database for the SVCoin tokens may be
maintained as a separate side chain from the database for each
Security token. In embodiments, one or more security tokens may be
maintained in the same side chain as the SVCoin tokens, and/or by
the same trusted entity system as used to maintain the SVCoin token
database.
[0660] In S9958, after the digital asset exchange system may
confirm that the user has sufficient SVCoin to cover the
transaction, as well as any other designated criteria, the digital
asset exchange system may initiate the process of redeeming the
designated SVCoin.
[0661] In S9958-a, the digital asset exchange system redeems the
designated SVCoin tokens, including updating the SVCoin token
ledger database to reflect the debiting and cancelling of the
designated tokens and debiting the corresponding digital wallet
address associated with such redeemed SVCoin tokens. In
embodiments, this process may be performed by generating a
transaction on the digital asset exchange network from a contract
digital wallet address or other authorized digital wallet address
under the relevant SVCoin smart contract programming, to be sent in
S9958-c, discussed below.
[0662] In S9958-b, the digital asset exchange system credits the
designated fiat funds to a fiat ledger associated with the user
account, and debit a corresponding amount of fiat from the SVCoin
fiat ledger being held in trust by the exchange.
[0663] In S9958-c, the digital assert exchange system publishes to
the blockchain network (e.g., the Ethereum Network) the transaction
to be recorded by the blockchain network. In embodiments, a
transaction fee (such as Gas) may be required by, e.g., a miner, to
process and add the requested transaction on the blockchain. In
embodiments, the transaction fee may be specified as an amount
and/or an amount limit to facilitate the transaction being
processed by a miner.
[0664] In S9960, the digital asset exchange computer system may
send a message to the registered user, and/or the designated
digital asset addresses to reflect that the transaction was
successfully processed. In embodiments, such messages may include
information including: (i) digital asset address; (ii) the amount
of tokens redeemed; and/or (iii) the new balances for the digital
asset address or digital wallet associated therewith.
Variable Permission Stable Value Tokens
[0665] FIGS. 14A-14H illustrate a method of issuing stable value
digital asset tokens. In embodiments, this method can control the
risk associated with loss of control of an on-line key pair by
using variable permission custodians.
[0666] In Step S1402, a first designated key pair, including a
first designated public key of an underlying digital asset and a
corresponding first designated private key, which is mathematically
related, is provided. The underlying digital asset may be
maintained on a distributed public transaction ledger maintained by
a plurality of geographically distributed computer systems in a
peer-to-peer network in the form of the blockchain (such as the
Ethereum blockchain or NEO blockchain). The first designated
private key may be stored on a first computer system which is
connected to the distributed public transaction ledger through the
Internet (e.g., in a hot wallet).
[0667] In Step S1404, a second designated key pair, including a
second designated public key of the underlying digital asset and a
corresponding second designated private key, which is
mathematically related, is provided. The second designated private
key is stored on a second computer system which is physically
separated from the first computer system and is not operatively or
physically connected to the distributed public transaction ledger
or the Internet (e.g., a cold wallet).
[0668] In embodiments, additional off-line designated key pairs may
also be provided.
[0669] In Step S1406, first smart contract instructions for a
stable value digital asset token associated with a first contract
address associated with the underlying digital asset are also
provided. The smart contract instructions are saved in the
blockchain for the underlying digital assets and include
instructions for: (1) token creation; (2) token transfer; (3) token
destruction; (4) authorization instructions for the first
designated key pair; and (5) authorization instructions for the
second designated key pair. In embodiments, these smart contract
instructions may be contained in one or a plurality of contract
addresses, as discussed above.
[0670] Referring to FIG. 14B, in Step S1408, a digital asset token
issuer system receives a request from a first requesting user to
obtain a first sum of stable value digital asset tokens in exchange
for a second sum of fiat. The first sum corresponds to the second
sum based on a fixed ratio of stable value digital asset token to
fiat (e.g., 1 SVCoin Token=1 USD). The first requesting user is
associated with an associated first requester key pair, including a
first request public key of the underlying asset and a
corresponding first request private key, which are mathematically
related to each other.
[0671] In Step S1410, the digital asset token issuer system
confirms receipt of the second sum of fiat.
[0672] In Step S1412, digital asset token issuer system determines
whether the first designated key pair has authority to obtain the
first sum of stable value digital asset tokens.
[0673] Referring to FIG. 14B, in the case where the digital asset
token issuer system determines in Step S1412 that the first
designated key pair has authority to obtain the first sum, in
embodiments, in Step S1414, the system may perform the steps S1414
A(1)-A(5). In Step S1414A(1), the digital asset token issuer
system, generates first instructions from the first designated
address to the contract address to obtain the first sum of stable
value digital asset tokens and transfer said first sum to the first
request public key. In Step S1414A(2), the digital asset token
issuer system sends to the first computer, the first instructions.
In Step S1414A(3), the first computer digitally signs the first
instructions using the first designated private key to generate
first digitally signed instructions. In Step S1414A(4), the first
computer sends to the digital asset token system, the first
digitally signed instructions. In Step S1414A(5), the digital asset
token system sends to the plurality of geographically distributed
computer systems, the first digitally signed instructions.
[0674] Referring to FIG. 14C, in the case where the digital asset
token issuer system determines in Step S1412 that the first
designated key pair has authority to obtain the first sum, in other
embodiments, in Step S1414' the system may perform the following
steps S1414 B(1)-B(3). In Step S1414B(1), a request is sent from
the digital asset token issuer system to the first computer, to
obtain the first sum of stable value digital asset tokens and
transfer said first sum to the first request public key. In Step
S1414B(2), the first computer generates first instructions
addressed from the first designated public key to the contract
address including a message to obtain the first sum of stable value
digital assets tokens and to assign the obtained first sum to the
first request public key, the first instructions including a
digital signature based on the first designated private key. In
Step 1414B(3), the first computer system sends to the plurality of
geographically distributed computer systems, the first
instructions. In embodiments, the first computer may send the first
instructions indirectly through another computer system.
[0675] Referring to FIG. 14D, in Step S1415, the digital asset
token issuer system confirms that the first sum of stable value
digital asset tokens has been obtained and transferred to the first
request public key based on reference to the blockchain.
[0676] In embodiments, in Step S1416, the digital asset token
issuer system may receive a second request to obtain a third sum of
stable value digital asset tokens in exchange for a fourth sum of
fiat. The third sum corresponds to the fourth sum based on the
fixed ratio of stable value digital asset token to fiat (e.g., 1 SV
Coin Token=1 USD). The second request may come from a second
requesting user with an associated second requester key pair,
including a second request public key of the underlying asset and a
corresponding second request private key, which are mathematically
related.
[0677] In Step S1418, the digital asset token issuer system
confirms receipt of the fourth sum of fiat.
[0678] In Step S1420, the digital asset token issuer system,
determines whether the first designated key pair has authority to
obtain the third sum.
[0679] In the case where the digital asset token issuer system
determines in Step S1420 that the first designated key pair does
not have authority to obtain the third sum, in Step S1422, the
digital asset token issuer system determines whether the second
designated key pair has authority to obtain the third sum.
[0680] Referring to FIG. 14E, in the case where the digital asset
token issuer system determines in Step S1422 that the second
designated key pair has authority to obtain the third sum, in
embodiments, the digital asset token issuer system perform the
Steps S1422A(1)-A(6). In Step S1422A(1), the digital asset token
issuer system generates second instructions from the second
designated address to the contract address to obtain the third sum
of stable value digital asset tokens and transfer said third sum to
the second request public key. In Step S1422A(2), the digital asset
token issuer system transfers to a portable memory device, the
second instructions. In Step S1422A(3), the second instructions are
transferred from the portable memory device to the second computer.
In Step S1422A(4), the second computer digitally signs the second
instructions using the second designated private key to generate
the second digitally signed instructions. In Step S1422A(5), the
second computer transfers to a second portable memory device, the
second digitally signed instructions. In Step S1422A(6), the second
digitally signed instructions are sent from the second portable
memory device to the plurality of geographically distributed
computer systems. In embodiments, the second digitally signed
instructions may be sent indirectly through another computer
system.
[0681] Referring to FIG. 14F, in the case where the digital asset
token issuer system determines in Step S1422' that the second
designated key pair has authority to obtain the third sum, in other
embodiments, in Step S1422', the system may perform the following
steps S1422B(1)-B(3). In Step S1422B(1), a request is sent from the
digital asset token issuer system to the second computer, to obtain
the third sum of stable value digital asset tokens and transfer
said third sum to the first request public key. In Step S1422B(2),
the second computer generates second instructions addressed from
the second designated public key to the contract address including
a message to obtain the third sum of stable value digital assets
tokens and to assign the obtained third sum to the second request
public key, the second instructions including a digital signature
based on the second designated private key. In Step 1422B(3), the
second computer system sends to the plurality of geographically
distributed computer systems, the second instructions. In
embodiments, the second computer may send the second instructions
indirectly through another computer system.
[0682] In Step S1424, the digital asset token issuer system
confirms that the third sum of stable value digital asset tokens
have been obtained and transferred to the second request public key
based on reference to the blockchain.
[0683] In embodiments, the step of sending, from the second
portable memory device to the plurality of geographically
distributed computer systems, the second digitally signed
instructions comprises the further steps of transferring, form the
second portable memory device to the digital asset computer system,
the second digitally signed instructions; and transferring, from
the digital asset computer system to the plurality of
geographically distributed computer systems, the second digitally
signed instructions.
[0684] Referring to FIG. 14G, in embodiments, a third designated
key pair, comprising a third designated public key of the
underlying digital asset and a corresponding third designated
private key that are mathematically related may be provided. The
third designated private key may be stored on a third computer
system which is physically separated from the first computer system
and from the second computer system and is not operatively or
physically connected to the distributed public transaction ledger
or the Internet. In such embodiments, the first smart contract
instructions further comprise authorization instructions for the
third key pair. Further, in such embodiments, in the case where the
digital asset token issuer system determines that the first
designated key pair does not have authority to obtain the third
sum, the method further comprises determining, by the digital asset
token issuer system, whether the third designated key pair in
addition to the second designated key pair have authority to obtain
the third sum; and in the case where the digital asset token issuer
system determines that the third designated key pair in addition to
the second designated key pair have authority to obtain the third
sum, perform the Steps S1422C(1)-C(6) as part of step S1422. In
Step S1422C(1), the digital asset token issuer system may generate
third instructions from the third designated address to the
contract address to obtain the third sum of stable value digital
asset tokens and transfer said third sum to the third request
public key. In Step S1422 C(2), the digital asset token issuer
system may transfer to a third portable memory device, the third
instructions. In Step S1422C(3), the third instructions may be
transferred from the third portable memory device to the third
computer. In Step S1422C(4), the third computer may digitally sign
the third instructions using the third designated private key to
generate the third digitally signed instructions. In Step
S1422C(5), the third computer may transfer to a fourth portable
memory device, the third digitally signed instructions. In Step
S1422C(6), the third digitally signed instructions may be sent from
the fourth portable memory device to the plurality of
geographically distributed computer systems. In embodiments, the
step of sending, from the fourth portable memory device to the
plurality of geographically distributed computer systems, the third
digitally signed instructions comprises the further steps of (i)
transferring, form the fourth portable memory device to the digital
asset computer system, the third digitally signed instructions; and
(ii) transferring, from the digital asset computer system to the
plurality of geographically distributed computer systems, the third
digitally signed instructions. In embodiments, the first portable
memory device and second portable memory device are the same
portable memory device. In embodiments, the first portable memory
device and second portable memory device are the different portable
memory devices. In embodiments, the third portable memory device
and fourth portable memory device are the same portable memory
device. In embodiments, the third portable memory device and fourth
portable memory device are the different portable memory
devices.
Blockchain Based Dividend Using Stable Value Coin
[0685] FIG. 11D illustrates an exemplary embodiment of a dashboard
Security Token interface which allow Security Token issuers to
provide instructions to transfer SVCoins to Security Token
holders.
[0686] Referring to FIG. 12, an exemplary process flow reflecting
an exemplary embodiment is shown where a Security Token issuer
initiates a transfer of SVCoins to Security Token holders. It will
be appreciated by those skilled in the art that the order of this
process may be modified consistent with embodiments of the present
invention.
[0687] In Step S1202, the Security Token issuer (who will generally
by a registered user with the digital asset exchange) will log into
the digital asset exchange. In embodiments, the SVCoin issuer is
any trusted entity, including a digital asset exchange, bank, trust
or other trusted entity. In embodiments, the Security Token issuer
will be an authorized user, or otherwise qualified with respect to
the trusted entity. In embodiments, the trusted entity may act as
agent of the Security Token issuer to generate, distribute and
maintain a ledger of SVCoins on behalf of the Security Token
issuer.
[0688] In Step S1204, the Security Token issuer system, or any
trusted entity system acting as agent, will navigate to the
dashboard Security Token interface (see, e.g., FIG. 11D) to
initiate a request for transfer of SVCoins to Security Token
holders. While for purposes of illustration, the request is made
via the dashboard Security Token interface, those of skill in the
art will appreciate that the request may be made via API calls,
submitted by electronic mail, and/or other electronic interactions,
consistent with embodiments of the invention. In embodiments, the
request shall identify: (i) the Security Token 1130; (ii) the total
amount of SVCoins to be distributed 1132; (iii) the Security Token
holder's digital asset addresses1134; (iii) the amount of SVCoins
to be distributed to each digital asset address1136; and/or (iv)
other information sufficient to calculate or otherwise determine
this information. In embodiments, this information may be provided
by providing the digital asset exchange, or other trusted entity
system acting on behalf of the SVCoin issuer, with the access to
the Security Token database, which would include the list of all
current Security Token holders and their respective digital asset
address and Security Token balances. In embodiments, the Security
Token database may include a list of all current Security Token
holders and digital asset addresses associated with each. In such
embodiments, the Security Token issuer, may still need to provide
the digital asset exchange system, or other trusted entity system,
with the amount of SVCoins to be distributed, either individually
and/or in total and how to prorate the distribution among Security
Token holders.
[0689] In Step S1206, the digital asset exchange system, or other
trusted entity system, may analyze and verify that the request can
be properly processed. In step S1206-a, the digital asset exchange
system, as the SVCoin issuer or on behalf of the SVCoin issuer, may
verify that the user has sufficient fiat currency maintained at the
digital asset exchange to cover the transaction, including a
sufficient amount of fiat to cover the amount of SVCoin being
acquired, as well as any transaction fees that may be charged. If
the user does not have sufficient fiat in the system, the
transaction may be terminated for insufficient funds. In
embodiments, the user may be provided an opportunity to obtain
sufficient funds, by, e.g., selling digital assets maintained by
the user on the digital asset exchange or by making a deposit of
additional fiat. In step S1206-b, the digital asset exchange
system, may also verify that the digital asset addresses, provided
are each a valid digital asset addresses. To the extent any digital
asset addresses are not verified, the transaction may be rejected,
and/or the digital asset exchange system may enter into a
reconciliation process with the Security Token issuer system or
trusted entity system.
[0690] At step 1206-c, the digital asset exchange system, or other
trusted entity system, may determine an amount of SVCoins to be
distributed to each of the digital addresses of the Security Token
holders. In embodiments, this determination may be made based on
the total number of Security Token holders and the total amount of
SVCoins requested by the Security Token issuer. In embodiments, the
Security Token issuer may designate a specific sum of SVCoins per
Security token. In embodiments, a total amount of SVCoins to be
purchased may be designated in the request of the Security Token
issue with directions to equally or proportionally divide the total
sum between the Security Token holders.
[0691] In S1208, after the digital asset exchange system, or other
trusted entity system, has confirmed that the user has sufficient
fiat to cover the transaction, the digital asset exchange system
may initiate the process of generating the requested SVCoin.
[0692] In S1208-a, the digital asset exchange system, or other
trusted entity system, may debit the designated fiat funds from a
fiat ledger associated with the Security Token issuer user account,
and credit a corresponding amount of fiat to the SVCoin fiat ledger
to be held in trust by the exchange. In embodiments, this fiat is
held in a custodial account of the exchange or an agent of the
exchange.
[0693] In S1208-b, the digital asset exchange system, or other
trusted entity system, shall generate instructions to generate the
requested SVCoin tokens, including instructions to update the
SVCoin token ledger database to reflect the addition of the new
tokens and the corresponding digital asset addresses associated
with such new SVCoin tokens.
[0694] In S1208-c, the digital asset exchange system, or other
trusted entity system, shall publish to the blockchain network
(e.g., the Ethereum Network) the transaction with instructions to
be recorded by the blockchain network. In embodiments, a
transaction fee may be required by, e.g., a miner, to process and
add the requested transaction on the blockchain.
[0695] In embodiments, where SVCoin tokens have already been
created and are maintained by the digital asset exchange system on
reserve, S1208 may be replaced with S1208' as follows. In step
1208-a', the digital asset exchange system, or other trusted entity
system, may debit the designated fiat funds from a fiat ledger
associated with the Security Token issuer user account, and credit
a corresponding amount of fiat to the SVCoin fiat ledger to be held
in trust by the exchange, or otherwise reserved by the trusted
entity.
[0696] At step S1208-b', the digital asset exchange computer
system, or other trusted entity system may then determine a portion
of the reserve for transfer based on the requested amount of SVCoin
identified by the Security Token issuer for transfer to the
Security Token holder(s).
[0697] At step 1208-c', the digital asset exchange computer system,
or other trusted entity system may update the SVCoin token ledger
to change the address associated with the determined portion of the
reserve SVCoin tokens to the address, or addresses, associated with
the Security Token holder.
[0698] In S1210, the digital asset exchange computer system may
send a message to the Security Token issuer registered user, and/or
each of the designated digital asset addresses to reflect that the
transaction was successfully processed. In embodiments, such
messages may include information including: (i) digital asset
address; (ii) the amount of tokens generated/or determined for
transfer; and/or (iii) the new balances for the digital asset
address or digital wallet associated therewith. In embodiments, the
message may include additional information related to the Security
Token, including: (iv) the amount of the Security Token held; (v)
the dividend issued; and/or (vi) instructions on how to redeem the
SVCoin.
EXAMPLES
[0699] The following examples illustrate embodiments of the present
invention. They are not intended to be limiting. It will be
appreciated by those of skill in the art that embodiments may be
applied to other use cases not specifically called out herein,
without departing from the present invention.
Example 1
Real Estate Investment Trust (REIT) Token
[0700] In embodiments, shares in a real estate investment trust
("REIT Trust") may be issued using a digital asset, such as a token
on the Ether Network ("REIT Token"). The REIT Trust may hold income
generating property such as real estate which is leased. As the
income generating property generates fiat profits which are
intended to be distributed to shareholders, a corresponding amount
of fiat is to be deposited with a digital asset exchange, such as a
regulated digital asset exchange like Gemini. The fiat is then
converted into a SVCoin by the Exchange. The SVCoin may then be
distributed on a pro-rata basis (or as otherwise instructed by the
REIT Trust) to REIT Token holders at the respective REIT Token
holder's digital asset addresses associated with the Ether Wallet
holding the REIT Token.
[0701] REIT Token holders may then use the SVCoin as a digital
asset to conduct other transactions. Eventually, the SVCoin can be
exchanged for fiat at the exchange based on the notional value
(e.g., 1 SVCoin=1 dollar).
Example 2
Energy Master Limited Partnership (Energy MLP) Tokens
[0702] In embodiments, shares in an Energy Master Limited
Partnership ("Energy MLP") may be issued using a digital asset,
such as a token on the Ether Network ("Energy MLP Token"). The
Energy MLP may offer shares (otherwise known as "units") in the
form of a digital asset, such as Energy MLP Tokens that are
publicly traded and which generate dividends to the shareholders.
As the dividends are distributed on a periodic basis in the form of
fiat currency, a corresponding amount of fiat is deposited with a
digital asset exchange, such as a regulated digital asset exchange
like Gemini. The fiat is then converted into a SVCoin by the
Exchange. The SVCoin may then be distributed on a pro-rata basis
(or as otherwise instructed by the Energy MLP) to Energy MLP Token
holders at the respective Energy MLP Token holder's digital asset
addresses associated with the Ether Wallet holding the Energy MLP
Token.
[0703] Energy MLP Token holders may then use the SVCoin as a
digital asset to conduct other transactions. Eventually, the SVCoin
can be exchanged for fiat at the exchange based on the notional
value (e.g., 1 SVCoin=1 dollar).
Example 3
Equity Security Tokens
[0704] In embodiments, equity shares corresponding to a stock
certificate in an entity may be issued using a digital asset, such
as a token on the Ether Network ("Equity Token"). As dividends
based on the Equity Token are generated for distribution to
shareholders, a corresponding amount of fiat is to be deposited
with a digital asset exchange, such as a regulated digital asset
exchange like Gemini. The fiat is then converted into a SVCoin by
the Exchange. The SVCoin may then be distributed on a pro-rata
basis (or as otherwise instructed by the entity distributing the
shares) to Equity Token holders at the respective Equity Token
holder's digital asset addresses associated with the Ether Wallet
holding the Equity Token.
[0705] Equity Token holders may then use the SVCoin as a digital
asset to conduct other transactions. Eventually, the SVCoin can be
exchanged for fiat at the exchange based on the notional value
(e.g., 1 SVCoin=1 dollar).
Example 4
Venture Capital (VC) Tokens
[0706] In embodiments, shares in a Venture Capital fund ("VC Fund")
may be issued using a digital asset, such as a token on the Ether
Network ("VC Token"). As the VC Fund generates returns to be
distributed to investors in the VC Fund, a corresponding amount of
fiat is to be deposited with a digital asset exchange, such as a
regulated digital asset exchange like Gemini. The fiat is then
converted into a SVCoin by the Exchange. The SVCoin may then be
distributed on a pro-rata basis (or as otherwise instructed by the
VC Fund) to VC Token holders at the respective VC Token holder's
digital asset addresses associated with the Ether Wallet holding
the VC Token.
[0707] VC Token holders may then use the SVCoin as a digital asset
to conduct other transactions. Eventually, the SVCoin can be
exchanged for fiat at the exchange based on the notional value
(e.g., 1 SVCoin=1 dollar).
Example 5
Private Equity (PE) Tokens
[0708] In embodiments, shares in a Private Equity fund ("PE Fund")
may be issued using a digital asset, such as a token on the Ether
Network ("PE Token"). As the PE Fund generates returns to be
distributed to investors in the PE Fund, a corresponding amount of
fiat is to be deposited with a digital asset exchange, such as a
regulated digital asset exchange like Gemini. The fiat is then
converted into SVCoin by the Exchange. The SVCoin may then be
distributed on a pro-rata basis (or as otherwise instructed by the
PE Fund) to PE Token holders at the respective PE Token holder's
digital asset addresses associated with the Ether Wallet holding
the PE Token.
[0709] PE Token holders may then use the SVCoin as a digital asset
to conduct other transactions. Eventually, the SVCoin can be
exchanged for fiat at the exchange based on the notional value
(e.g., 1 SVCoin=1 dollar).
Example 6
Digital Certificate of Deposit (CD) Tokens
[0710] In embodiments, digital certificate of deposits ("Digital
CD") may be issued using a digital asset, such as a token on the
Ether Network ("CD Token"). As interest amounts are generated based
on the terms of the certificate of deposits, a corresponding amount
of fiat is to be deposited with a digital asset exchange, such as a
regulated digital asset exchange like Gemini. The fiat is then
converted into a SVCoin by the Exchange. Upon maturity of the
Digital CD (or before maturity), the SVCoin may then be distributed
on a pro-rata basis (or as otherwise instructed by the Digital CD
issuer and/or less any premature withdrawal penalty) to CD Token
holders at the respective CD Token holder's digital asset addresses
associated with the Ether Wallet holding the CD Token.
[0711] CD Token holders may then use the SVCoin as a digital asset
to conduct other transactions. Eventually, the SVCoin can be
exchanged for fiat at the exchange based on the notional value
(e.g., 1 SVCoin=1 dollar).
Example 7
Digital Bond Tokens
[0712] In embodiments, digital bonds may be issued using a digital
asset, such as a token on the Ether Network ("Bond Token"). As
interest amounts are generated based on the coupon rates of the
digital bonds, a corresponding amount of fiat is to be deposited
with a digital asset exchange, such as a regulated digital asset
exchange like Gemini. The fiat is then converted into SVCoin by the
Exchange. The SVCoin may then be distributed on a pro-rata basis
(or as otherwise instructed by the digital bond issuer) to Bond
Token holders at the respective Bond Token holder's digital asset
addresses associated with the Ether Wallet holding the Bond
Token.
[0713] Bond Token holders may then use the SVCoin as a digital
asset to conduct other transactions. Eventually, the SVCoin can be
exchanged for fiat at the exchange based on the notional value
(e.g., 1 SVCoin=1 dollar).
Example 8
Peer-to-Peer Lending (P2P) Tokens
[0714] In embodiments, a peer-to-peer lending service ("P2P
Service") may issue a digital asset, such as a token on the Ether
Network ("P2P Loan Token"). As lending amounts and interest
payments are distributed, corresponding amounts of fiat is
deposited with a digital asset exchange, such as a regulated
digital asset exchange like Gemini. The fiat is then converted into
SVCoin by the Exchange. The SVCoin may then be distributed on a
pro-rata basis (or as otherwise instructed by the lender/borrower)
to P2P Loan Token holders at the respective P2P Loan Token holder's
digital asset addresses associated with the Ether Wallet holding
the P2P Loan Token.
[0715] P2P Loan Token holders may then use the SVCoin as a digital
asset to conduct other transactions. Eventually, the SVCoin can be
exchanged for fiat at the exchange based on the notional value
(e.g., 1 SVCoin=1 dollar).
Example 9
Crowdfunding (CF) Tokens
[0716] In embodiments, a Crowdfunding service may issue a digital
asset, such as a token on the Ether Network ("CF Token"). As funds
are collected, a corresponding amount of fiat is to be deposited
with a digital asset exchange, such as a regulated digital asset
exchange like Gemini. The fiat is then converted into a SVCoin by
the Exchange. The SVCoin may then be distributed on a pro-rata
basis (or as otherwise instructed by the Crowdfunding service) to
CF Token holders at the respective CF Token holder's digital asset
addresses associated with the Ether Wallet holding the CF
Token.
[0717] CF Token holders may then use the SVCoin as a digital asset
to conduct other transactions. Eventually, the SVCoin can be
exchanged for fiat at the exchange based on the notional value
(e.g., 1 SVCoin=1 dollar).
Example 10
Real Estate Crowdsourcing Tokens
[0718] In embodiments, a Real Estate Crowdsourcing services may
issue a digital asset, such as a token on the Ether Network ("RE
Token"). As funds are collected, a corresponding amount of fiat is
to be deposited with a digital asset exchange, such as a regulated
digital asset exchange like Gemini. The fiat is then converted into
a SVCoin by the Exchange. The SVCoin may then be distributed on a
pro-rata basis (or as otherwise instructed by the Real Estate
Crowdsourcing service) to RE Token holders at the respective RE
Token holder's digital asset addresses associated with the Ether
Wallet holding the RE Token. RE Token holders may then use the
SVCoin as a digital asset to conduct other transactions.
Eventually, the SVCoin can be exchanged for fiat at the exchange
based on the notional value (e.g., 1 SVCoin=1 dollar).
Example 11
Artistic/Digital Rights Payment Tokens
[0719] In embodiments, tokens may be issued against an artistic
work, such as a song or movie (DR Token), for example, as a token
on the Ethereum network. As royalties are collected for use of the
song or movie, a corresponding amount of fiat may be deposited with
a digital asset exchange. The fiat may be converted into SVCoin and
distributed on a pro-rata basis to the rights holders who are DR
Token holders. More specifically, the SVCoin may be transferred the
digital asset address associated with a wallet of a DR Token holder
as a payment of royalties.
[0720] In embodiments, of the examples discussed above, the token
holders may instigate payment of SVCoin by sending a request for
payment. In this case, any transaction fees will be the
responsibility of the token holder. In embodiments, the token
issuer, or an agent thereof, may implement or instruct distribution
of payments in which case transaction fees are the responsibility
of the token issuer.
Setup and Storage of Digital Assets and/or Digital Wallets
[0721] Digital asset accounts may be securely generated, accessed,
and/or used (e.g., for transactions) from a secure administrative
portal. In embodiments, the administrative portal, which may be
used for key generation, parsing, and/or reassembly, may be a
secure system for transacting in digital math based assets
comprising a first computer system comprising one or more
processors that generate one or more digital wallets and one or
more respective private keys and one or more respective public
keys, each of the one or more private keys being segmented into one
or more private key segments; one or more writing devices
operatively connected to the one or more first computer systems,
each of the one or more writing devices adapted to write at least
one private key segment of a corresponding one of the one or more
private keys, along with information correlating the at least one
private key segment to one of the one or more public keys; and at
least one networked computer comprising one or more processors that
access at least one of the digital wallets using a corresponding
one of the one or more private keys as reassembled using the
corresponding private key segments.
[0722] In embodiments, the administrative portal may further
comprise a second computer system comprising one or more processors
for reassembling the corresponding one of the one or more private
keys based on input into the second computer system of the
corresponding private key segments. In embodiments, the input
device may be a scanner, a keyboard, a touchscreen, a mouse, a
microphone, a camera, and/or a digital card reader, to name a
few.
[0723] In embodiments, the first computer system of the
administrative portal and/or the second computer system may not be
associated with a network. In embodiments, the first computer
system of the administrative portal and the networked computer
system may be a common computer system. In embodiments, the second
computer system of the administrative portal and the networked
computer system may comprise a common computer system. In further
embodiments, the first computer system, the second computer system,
and the networked computer system may be a common computer
system.
[0724] In embodiments, referring to FIGS. 29A-29D, the
administrative portal may comprise an accounting computer 25 and a
secure location 10, as described herein.
[0725] Referring to the exemplary embodiment illustrated in FIG.
29A, at a secure location 10, a digital asset account holder,
administrator, manager, and/or custodian may maintain at least two
computers. In embodiments, an administrator, manager, and/or
custodian may be contracted to manage one or more digital asset
accounts and/or oversee security for the accounts. In embodiments,
secure location 10 may be a room with restricted entry. In
embodiments, secure location 10 may have a user entry log to
provide an access record for the location.
[0726] In the exemplary embodiment depicted in FIG. 29A, at secure
location 10, the first computer may be a networked computer 20,
which may comprise one or more computing devices. Networked
computer 20 and/or other computers in the system may have the
ability to cycle or otherwise change IP addresses. The second
computer may be a non-networked, isolated computer 30, which may
comprise one or more computing devices. In embodiments, the
networked computer 20 and the isolated computer 30 may be separate
aspects of one computing device. For example, a hard drive
partition may be used to separate the networked and non-networked
functions. In embodiments, the computers may comprise one or more
processors and/or computer readable memory. Networked computer 20
and isolated computer 30 may be located in close proximity to each
other, as in the same room, or may be located in separate locations
within secure location 10. It will be appreciated by those in the
art that secure location 10 may comprise a plurality of secure
locations. In embodiments, isolated computer 30 may be located in a
Faraday cage 50. The Faraday cage 50 may prevent electronic
eavesdropping or interference from electromagnetic waves. In
alternative embodiments, the functions ascribed above to networked
computer 20 and isolated computer 30 may be performed by one or
more networked and/or isolated computers at one or more
locations.
[0727] In the exemplary embodiment depicted in FIG. 29A, networked
computer 20 can communicate with a registry, exchange, other
external entities, e.g., APs, and/or all or part of a digital asset
network to send and/or receive digital assets (e.g., to create
transactions), to compute balances, and/or to transmit or otherwise
broadcast signed or otherwise finalized transactions. In
embodiments, networked computer 20 may be used to distribute
digital assets among one or more digital asset accounts and/or
digital wallets. The networked computer 20 may be connected to the
Internet directly (e.g., through Ethernet, Wi-Fi, Bluetooth, or any
connection known in the art or hereafter developed) or indirectly
(e.g., through another computer to which it is directly connected),
or may be connected to a network other than the Internet.
[0728] In embodiments, the digital assets may be stored in one or
more digital wallets residing on one or more computing devices,
such as remote servers, personal computers, tablet devices, mobile
devices, such as smart phones, or PDAs, to name a few. In the
exemplary embodiment of FIG. 29A, isolated computer 30 may be used
to generate electronic wallets and/or key pairs, which may include
both private and public keys. In embodiments, keys comprise strings
or alphanumeric characters or other characters, optionally of a
pre-determined length, may comprise one or more pieces of computer
code, or may comprise other formats of keys known in the art. In
embodiments, digital wallets may be created on isolated computer 30
using a "clean-boot" with a bootable CD, such as a Linux Live CD.
The specific version of the operating system may be maintained in
secret to avoid security risks.
[0729] In embodiments, digital asset accounts and/or digital
wallets may be generated by an entity upon receipt of a request to
transfer digital assets to the entity and/or may be pre-generated
at the time that security measures (e.g., a vault storage system)
is set up, to name a few. The digital asset accounts each may be
associated with unique private-public key pairs (which may include
a plurality of private keys). In embodiments, the key pairs may be
created as part of the digital wallet creation process. In other
embodiments, the key pairs may be created before or after the
creation of the one or more digital wallets and associated with the
wallets as a separate step. In embodiments, the assets stored in a
digital wallet may be accessed with a key pair, even if the
original wallet is destroyed or otherwise unavailable. In such
embodiments, only the key pair need be maintained and/or stored to
retrieve the assets associated with a given digital wallet.
Accordingly, in an embodiment of the present invention, digital
wallets may be deleted or otherwise destroyed following the storage
of their associated keys. Assets may be added to the wallet even
after its destruction using the public key. Assets may thus be
stored in a wallet after the wallet is destroyed. The wallet may be
re-generated using its keys.
[0730] In embodiments, the private key may not be used directly
with or on the networked computer 20. In embodiments, a public key
(without the corresponding private key) may only be able to receive
digital assets for deposit purposes. In embodiments, assets may be
transferred to a wallet using its public key and without the
transferor knowing the private key. Implementation of the foregoing
may require customized software, e.g., software that modifies the
standard digital asset protocols.
[0731] In embodiments, isolated computer 30 may also be used in
conjunction with, e g., one or more printers or other writing
devices, to print the key pairs or may be used otherwise to arrange
for the storage of one or more aspects and/or portions (or segments
or coded and/or encrypted segments) of the key pairs. A printer 32
or other writing device to write, print, or otherwise store the
keys may be provided with the isolated computer 30. Such printer(s)
and/or other writing device(s) may be connected, directly and/or
indirectly, to the isolated computers, such as through hardwire,
wireless, or other connection. That device may also be located
within a Faraday cage, which may be the same Faraday cage housing
isolated computer 30. Storage of the keys is described further
below.
[0732] In embodiments, one or more isolated computers 30 can be
used in conjunction with one or more printers or other writing
devices to write, print or otherwise store keys. It will be
appreciated by one of skill in the art, that In embodiments, it may
be desirable to limit the number or printers or other writing
devices to as few as possible to reduce risk of exposure of private
keys, while In embodiments, it may be desirable to have a larger
number of printers or other writing devices to handle the volume of
wallets and/or keys that need to be generated and/or written by the
system for its operation.
[0733] Private keys may be stored in the selected format along with
their corresponding public keys. In embodiments, the private key
may be stored with a reference number which may correlate the
private key to its corresponding public key. The reference number
may be (or may be stored as) a number, alphanumeric code, bar code,
QR code, to name a few. A reference number master list may identify
a private key, the reference number, and the corresponding public
key. The reference number master list may be printed or etched on
paper or some other substrate, may be stored digitally on a tape
CD, DVD, computer hard drive, or other medium, or otherwise stored
in a manner known in the art. The substrates or media just
described may have any suitable size, including microscopic or nano
scales. In embodiments, the reference number master list may be
stored in a secure storage chamber 60 at secure location 10.
Storage chamber 60 may be a lockbox, fireproof box, or other secure
chamber. If storage is electronic or digital, chamber 60 may
protect against electromagnetic waves.
[0734] The private and/or public keys and/or any reference number
may be stored in a variety of formats, as described herein. The
keys may be divided into separate segments for storage. For
example, a 51-character key may be divided into three 17-character
segments. The same reference number that correlates the private key
to the public key or an additional reference number or other
identifier may indicate which key segments are part of the same
key. The reference identifier or another identifier may be provided
and stored with the one or more segments to indicate their order in
the assembled key. A numbering schema or other convention may also
be used to identify the order of key segments. For example, a first
segment may begin with an "A", a second segment may begin with a
"B", and a third segment may begin with a "C". The key segments may
be stored in one or more locations. In embodiments, the key
segments may be divided among a plurality of vaults 70, as
described herein.
[0735] In embodiments, keys and/or key segments may be stored
digitally and/or electronically, e.g., on one or more computer hard
drive, disk, tape, memory card, flash memory, CD-ROM, and/or DVD,
to name a few. In embodiments, the keys and/or key segments may be
printed on any substrate, including paper, papyrus, plastic, and/or
any substrate known in the art. In embodiments, the substrate may
be fireproof or fire resistant, such as a fireproof plastic. The
substrate may be resistant to fluids, e.g., water resistant, or
otherwise nonabsorbent. Other printing options may be holographic
printing, three-dimensional printing, raised printing, such as
Braille lettering, and/or invisible ink printing, such as using
inks that require a special light and/or treatment, e.g., heat
and/or chemicals, for viewing. In embodiments, keys may be etched,
e.g., in wood, metal, glass, plastic, or other compositions known
in the art, e.g., to produce a card. In embodiments, a magnetic
encoding may be used to write to the card. In embodiments, etched
or printed keys or key segments may take any shape, such as
coin-shaped tokens or rectangular blocks, to name a few. In
embodiments, keys or key segments may be printed, etched, or
otherwise stored as alphanumeric strings. In embodiments, keys or
key segments may be printed, etched, or otherwise stored in a form
readable by programmed devices, such as scanners. Such a form may
be a QR code, a bar code, another available scanable code format
and/or a proprietary code format. In embodiments, quality control
operations may ensure that the keys or key segments are printed
accurately and/or are able to be read. In embodiments, printed or
etched keys or key segments may be coated to prevent reading the
key without removing or otherwise altering the coating. Such a
coating may be a UV coating and/or may block X-rays or other forms
of scanning or reading. The coating may be scratched off to reveal
the data contained below it. The back of the substrate may also be
coated to prevent reading through the substrate. Such a coating may
provide an indication of whether a printed key or key segment was
accessed or attempted to be accessed (e.g., it can be detected
whether someone scratched the coating away).
[0736] In embodiments, security measures may be established and
implemented to reduce the risk of digital wallets being
compromised. Further, redundancies can be put in place to provide
and/or help ensure that any information necessary to access digital
math-based assets in digital wallets can be maintained and/or
accessed by the account holders as appropriate, necessary, and/or
desired.
[0737] Multiple private keys may be required to access a digital
wallet. Multiple keys may be stored in the same manner as key
segments. In embodiments, where a second private key is required,
the one or more individuals or systems providing the second key may
be located in different administrative portals, different rooms,
and/or different geographies from the one or more individuals or
systems providing the first private key. Accordingly, a plurality
of administrative portals may be employed by secure digital asset
storage systems in accordance with the present invention. In
embodiments, a plurality of portals may be used for retrieval of
stored digital assets (e.g., by requiring a signature or private
key from at least two individuals located in at least two different
portals). In embodiments, one portal may be used for re-assembling
key segments and thus providing one private key, and an individual
in a second location may be required to provide a second key or
signature before a digital wallet may be accessed. The second key
or signature may be encrypted and/or segmented as described herein
with respect to a single private key.
[0738] In embodiments, a digital wallet may have more than one
private key (e.g., multi-signature wallets). The plurality of
private keys may be stored securely in the same manner as a single
private key. Each private key segment pertaining to a single wallet
may be stored in separate vaults, which may be electronic and/or
physical vaults. By allowing for multi-signature wallets, the
wallet can provide for approval/signature authority from more than
one individual or entity as a further means to control access to
digital assets held in such wallet. In embodiments, a signature
authority may be an automated electronic signature authority, such
as a computer or computer system programmed with transaction
approval rules. The automated electronic signature authority may
only provide a signature when a transaction satisfies the
transaction approval rules. In other embodiments, required
signature authorities may be individuals who may be located in
different administrative portals, different rooms, and/or different
geographies. Accordingly, a plurality of administrative portals may
be employed by secure digital asset storage systems in accordance
with the present invention. In embodiments, one portal may be used
for re-assembling key segments and thus providing one private key,
and an individual or system in a second location may be required to
provide a second key or signature before a digital wallet may be
accessed. The second location may be a second portal, a location in
a different building, and/or a different geography, to name a few.
The second key or signature may be encrypted and/or segmented as
described herein with respect to a single private key.
[0739] Keys or key segments may be encrypted and/or ciphered, using
one or more ciphers, as an additional security measure. The
encryption and/or ciphers may be applied by computers running
encryption software, separate encryption devices, or by the actions
of one or more persons, e.g., prior to input of the encrypted
and/or ciphered data into one or more computers. In embodiments, a
key may be stored in reverse order and/or translated (e.g., by
adding 1 to each digit and/or advancing each alphabetic character
by one position in the Western alphabet, by substitution such as by
mapping each character to a different character (e.g., A=3, 5=P, to
name a few), to name a few). In embodiments, other encryption
algorithms can comprise scrambling of a sequence of characters,
addition of characters, and/or hashing. Other encryption techniques
are possible. See, e.g., David Kahn, The Codebreakers: The Story of
Secret Writing, 1967, ISBN 0-684-83130-9. See also, Bruce Schneier,
Applied Cryptography, John Wiley & Sons, 1994, ISBN:
0-471-59756-2. The encryption and/or ciphers may protect against
use of the keys by an unauthorized entity who obtains the keys or
key segments or copies thereof. The encoding and/or cipher may be
maintained in secret and applied to decrypt or decode the keys only
when keys must be accessed and used. In embodiments, ciphering may
refer to an alphanumeric translation or reordering, while
encryption may refer to higher level algorithms, including hashing
algorithms. In embodiments, encryption and ciphering may refer to
the same processes, in which case descriptions herein of processes
involving both encryption and ciphering steps may only entail
performance of one such step so as not to be repetitive.
[0740] Following storage of the key pairs, the key pairs may be
erased from isolated computer 30. Erasure may occur using the
computer operating system's delete features, customized software or
computer code designed to remove the data from computer memory,
magnets used to physically erase the data from the computer's
storage drives, and/or other techniques known in the art.
[0741] A key reader 40 may be provided to assemble, read, and/or
de-crypt the keys or key segments. The key reader 40 may be
contained within a Faraday cage, which may be the same Faraday cage
housing isolated computer 30. The key reader 40 may read keys that
are printed, etched, digitally stored, or otherwise stored. Key
reader 40 may be a scanner (e.g., photo scanner or bar code
scanner), QR reader, laser, computer hardware, CD reader, and/or
digital card reader, to name a few. Key reader 40 may include or be
operationally connected to a microscope or magnifying device, such
as for keys that are printed in microscopic sizes or other small
sizes. In embodiments, key reader 40 may be paired with optical
character recognition ("OCR") technology to create digitally
recognized copies of keys that may have been printed, etched, or
otherwise stored in a form not immediately readable by a
computer.
[0742] In embodiments, key reader 40 may comprise an input device,
such as a keyboard, touchscreen, mouse, and/or microphone, to name
a few. An input device may be used for manual entry of keys and/or
key segments into one or more computers so that the computer may
further process the key segments. Key reader 40 may be
operationally connected to isolated computer 30, which may be a
direct connection (e.g., a USB cable, Ethernet cable, Bluetooth, or
Wi-Fi, to name a few). In embodiments, key reader 40 may be
operationally connected to networked computer 20. Key reader 40 may
be operationally connected to a separate computing device.
[0743] In embodiments, reassembled keys may be input directly into
a networked computer 20, which may then be used to access one or
more digital wallets and/or perform one or more transactions. Key
reader 40 and/or corresponding software (e.g., running on a
computer operationally connected to the key reader) may be
programmed or otherwise designed to assemble key segments into
completed keys. Key reader 40 and/or corresponding software (e.g.,
running on a computer operationally connected to the key reader)
may also correlate the private keys with their corresponding public
keys, optionally using the reference number master list. In
embodiments, one or more pieces of software may be used to
retrieve, decrypt, assemble, and/or decipher keys and/or key
segments. In embodiments, such software may be run on any of one or
more secure storage system computers and/or user devices. In
embodiments, multiple authority may be required to initiated a
retrieval of stored private keys.
[0744] In embodiments, a back-up isolated computer 35 and/or a
back-up key reader 45 may be provided at secure location 10, as
illustrated in FIGS. 29A-29C. The back-up isolated computer 35 and
key reader 45 may be contained in a back-up Faraday cage 55, which
may be separate from main Faraday cage 50. In embodiments, all or
part of the administrative portal may be duplicated and/or backed
up. A duplicate administrative portal or portion thereof may be
located in a separate geographic area. A duplicate portal may serve
as a disaster recovery operations portal.
[0745] In embodiments, a digital math-based asset miner, such as a
bitcoin miner, may be located at or within the administrative
portal. The miner may be one or more computers. In embodiments, the
miner may be operationally connected to any of the computers and/or
devices at the administrative portal described above.
[0746] In embodiments, referring to FIG. 29D, the secure location
can house one or more networked computers 20, one or more
accounting computers 25, one or more digital asset miner computers
65, one or more isolated transaction computers 32 operatively
connected to one or more key readers 40, and one or more isolated
wallet computers 30', operatively connected to one or more writing
devices 32 and, in embodiments, to one or more key readers 40. Each
isolated transaction computer 60 and/or isolated wallet computer
30' may be isolated from each other and/or other computers
electronically using a secure environment, such as a Faraday cage
50, 60.
[0747] One or more vaults 70, 70-1, 70-2, 70-3,70-N, may be used to
hold assets. Vaults may be any secure storage facilities,
structures, and/or systems. For example, a vault may be a bank
vault or a safety deposit box. Vaults may have appropriately
controlled environments (e.g., regulated temperature and/or
humidity, to name a few) to enable long-term storage of keys and/or
key segments substrates. Vaults may be operated by one or more
entities, which may be separate entities. In embodiments, only
bonded employees may be permitted access to the vaults. Also,
vaults may be located in one or more physical (e.g., geographic)
and/or digital (e.g., residing on one or more separate computer
servers or hard drives) locations. In embodiments, vaults may be
used in conjunction with digital wallets and/or other devices
and/or systems known in the art for storing digital assets and/or
data.
[0748] In the exemplary embodiments of FIGS. 29A-29D, the private
keys 80 may be divided into three segments, 80-1, 80-2, and 80-3
for storage. Each segment may be stored in a separate one of vaults
70-1, 70-2, and 70-3. In embodiments, two segments, four segments,
five segments or another number of segments can be used in
accordance with embodiments the present invention. In embodiments,
each key segment may be stored in a vault operated by the same
entity or by one or more different entities.
[0749] In embodiments, one or more duplicate copies of each key or
key segment may be produced. Such duplicate copies may be stored in
separate vaults, e.g., three sets of keys split into three segments
may be stored in nine vaults, four sets of keys split into two
segments may be stored in eight vaults, and/or the copies of key
segments may be distributed among some other number of vaults, to
name a few. See, e.g., FIGS. 29A-29D, to name a few. Duplicate
copies may serve as a back-up in case one copy of a key or key
segment becomes corrupted, lost, or otherwise unreadable.
[0750] In embodiments, vaults may hold the keys in an organized or
categorized fashion so as to facilitate location of one or more
keys or key segments. In embodiments, a sorting reference number
may be used to organize the keys or key segments. The sorting
reference number may be the same as the reference number that
correlates private and public keys. In embodiments, etched coins or
other materials or printed keys or key segments may be stacked or
otherwise arranged according to the reference number. In
embodiments, an index or card catalog may describe the location of
the keys. In embodiments, an automated machine may store and
retrieve key segments from storage slots, which machine may receive
an input to indicate which keys or key segments to retrieve.
[0751] FIGS. 30A-30D illustrate exemplary embodiments of the
present invention where one or more computers 25 running accounting
software to account for the assets and/or expenses of an account
holder can be located either within the secure location 10 (e.g.,
FIG. 30B) or outside of the secure location 10 (e.g., FIG. 30C). In
embodiments, such accounting software as well as possibly other
software may be stored, accessed and/or operated on one or more
networked computers 20 in the secure location 10. In embodiments,
the accounting computer 25 may be the same or different from
isolated computer 30 and/or networked computer 20 and/or a mining
computer.
Digital Wallets
[0752] In embodiments, digital math-based assets can be stored
and/or transferred using either a website or software, such as
downloaded software. The website and/or downloadable software may
comprise and/or provide access to a digital wallet. Each digital
wallet can have one or more individual digital asset accounts
(e.g., digital asset addresses) associated with it. Each user can
have one or more digital wallets to store digital math-based
assets, digital cryptocurrency, assets and the like and/or perform
transactions involving those currencies or assets. In embodiments,
service providers can provide services that are tied to a user's
individual account.
[0753] Digital wallets and/or the digital asset accounts associated
with and/or stored by a digital wallet may be accessed using the
private key (which may be used in conjunction with a public key or
variant thereof). Accordingly, the generation, access, use, and
storage of digital asset accounts is described herein with respect
to generation, access, use, and storage of digital wallets. Such
descriptions are intended to be representative of digital asset
accounts and not exclusive thereof.
[0754] A digital wallet can be generated using a digital asset
client 110 (e.g., a Bitcoin client). In embodiments, a digital
wallet can be created using a key pair system, such as an
asymmetric key pair like a public key and a private key. The public
key can be shared with others to designate the address of a user's
individual account and/or can be used by registries and/or others
to track digital math-based asset transactions involving a digital
asset account associated with the digital wallet. Such transactions
may be listed or otherwise identified by the digital wallet. The
public key may be used to designate a recipient of a digital asset
transaction. A corresponding private key can be held by the account
holder in secret to access the digital wallet and perform
transactions. In embodiments, a private key may be a 256-bit
number, which can be represented by a 64-character hexadecimal
private key and/or a 51-character base-58 private key. As discussed
herein, private keys of other lengths and/or based on other
numbering systems can be used, depending upon the user's desire to
maintain a certain level of security and convenience. Other forms
of key pairs, or security measures can be used consistent with
embodiments of the present invention.
[0755] In embodiments, a digital wallet may store one or more
private keys or one or more key pairs which may correspond to one
or more digital asset accounts.
[0756] In embodiments, a digital wallet may be a computer software
wallet, which may be installed on a computer. The user of a
computer software wallet may be responsible for performing backups
of the wallet, e.g., to protect against loss or destruction,
particularly of the private and/or public key. In embodiments, a
digital wallet may be a mobile wallet, which may operate on a
mobile device (e.g., mobile phone, smart phone, cell phone, iPod
Touch, PDA, tablet, portable computer, to name a few). In
embodiments, a digital wallet may be a website wallet or a web
wallet. A user of a web wallet may not be required to perform
backups, as the web wallet may be responsible for storage of
digital assets. Different wallet clients may be provided, which may
offer different performance and/or features in terms of, e.g.,
security, backup options, connectivity to banks or digital asset
exchanges, user interface, and/or speed, to name a few.
[0757] The digital asset exchange computer system 3230 may be used
to convert digital assets into fiat or other digital assets as well
as to exchange fiat for digital assets. In embodiments, a digital
asset exchange computer system 3230 may include one or more
databases that are used to store user account authentication data,
fiat account data, digital wallet data, digital asset customer
account data and transaction data, including transaction parameters
and transaction instructions. A digital wallet system is
operatively connected to a decentralized digital asset network that
uses a decentralized electronic ledger in the form of a blockchain
maintained by a plurality of physically remote computer systems to
track at least one of asset ownership or transactions in a digital
asset exchange system. The digital wallet system includes one or
more digital wallet modules. FIG. 23 illustrates an exemplary
process by which the digital exchange computer system including the
digital wallet system conducts transactions. The digital wallet
system receives, from a user device, transaction instructions and
one or more transaction parameters associated with a transaction as
indicated in step S3802. In embodiments, the transactions
parameters include on or more of (1) a digital asset strike price
as a threshold for sale of a specified amount of digital assets
when the price equals, rises above or falls below a predefined
threshold, wherein the amount of digital assets to transact may be
specified in a different denomination; (2) digital asset
denominations; (3) digital asset amounts; (4) time periods; (5)
rates of change; or (6) absolute amounts of change. The transaction
instructions include at least one of the following (1) buy; (2)
sell; (3) hold; or (4) convert to a different denomination of
digital asset or fiat currency.
[0758] In embodiments, the digital wallet system generates
transaction rules for automatic digital asset transactions based at
least the one or more received transaction parameters and the
received transaction instructions as indicated at step S3804. The
transaction rule include computer code running on the one or more
computers to perform a transaction when one or more specified
conditions are met or not met, based on the rules.
[0759] In embodiments, the digital wallet system accesses
transaction data including price data associated with the specified
amount of digital assets and stores the transaction data in the one
or more databases as indicated in step S3806. In an embodiment the
digital wallet system may access the transaction data using an
application programming interface of an exchange agent. At step
S3808, the digital wallet system evaluates the price data according
to the transaction rules and, at step S3810, performs automated
transactions when pre-defined conditions are met or not met in
accordance with the transaction rules and the price data. This
evaluation may include testing the transaction data against one or
more logical conditions embodied in the transaction rules. In
embodiments, these logical conditions include determining at least
one of whether the digital asset price has reached or crossed a
threshold value; or whether a rate of change in price has reached
or crossed a threshold value. The digital wallet system may format
the transaction data to be compatible with the digital wallet
system.
[0760] In embodiments, at step S3812, the digital wallet system may
generate one or more notifications to one or more user devices,
with the notices includes at least one of a status update on
transactions; notification of at least one of incomplete, pending
or failed transactions; a log of all transactions as performed by
at least one of the digital wallet system or by a user and a log of
all transaction opportunities, including transactions declined or
not otherwise authorized and transmits the one or more
notifications to the user devices.
[0761] The digital asset exchange computer system also includes a
fund transfer system including a fiat account funding and
redemption system, a digital asset account funding and redemption
system operatively connected to the digital wallet system and
operatively connected to the decentralized digital asset network
and a settlement engine operatively connected to the decentralized
digital asset network and configured to carry out transactions. The
settlement engine may be configured to process specified customer
transactions to purchase or sell digital assets according to a
user's instructions, if certain user specified factors are met. The
user specified factors include that at least one of digital assets
are: (a) within a given price, (b) quantity, or (c) period of time.
In embodiments, the settlement engine may perform steps of holding,
by the digital asset exchange computer system, funds in escrow
until a buyer's payment of fiat is received into a bank account;
receiving, by the digital asset exchange computer system from a
digital asset buyer device, a notification of received digital
assets from a digital asset seller; and providing, by the digital
asset exchange computer system to a bank computer system associated
with a digital asset exchange bank, an instruction to release the
digital asset buyer's funds to the digital asset seller. The
settlement engine may include pre-program instructions to transfer
an amount of digital assets from a seller wallet to at least one
buyer wallet upon the occurrence of user specified conditions.
[0762] In embodiments, the transaction may be at least one of
formation, buying and selling of derivative products, including
call options and put options. In embodiments, the transaction may
be at least one or more of digital asset lending, delayed
settlements, derivative swaps, futures and forwards.
[0763] In embodiments, the digital asset account funding and
redemption system is configured to process funding of a digital
asset account held by the exchange from an exchange customer by
receiving, by the digital asset exchange computer system, an
initial transfer of digital assets; receiving, by the digital asset
exchange computer system, a confirmation of clearance of the
digital asset transfer; and updating, by the digital asset exchange
computer system, an existing customer account in the one more or
more databases with the received digital assets including making an
electronic entry in an exchange digital asset electronic ledger and
providing a notification that digital assets are received.
[0764] In embodiments, the digital asset account funding and
redemption system is configured to process withdrawing a digital
asset account held by the exchange from an exchange customer. For
example, the digital asset account funding and redemption system
may provide a withdrawal interface to a first customer user device
associated with a first customer, receive user first withdrawal
data including at least a first destination wallet address and a
first request digital wallet asset withdrawal amount value from the
first customer user device, verify that the first digital asset
account associated with the first customer contains sufficient
digital assets to cover the requested withdrawal amount by reading
a digital asset electronic ledger to determine a first digital
asset account balance; update the exchange digital asset electronic
ledger to reflect the first withdrawal data as pending, execute a
first withdrawal based on the first withdrawal data by broadcasting
the first withdrawal to a digital asset network electronic ledger,
monitor the network digital asset ledger to determine that a
transaction based on the first withdrawal is confirmed and update
the digital asset ledger to reflect confirmation of the first
withdrawal. In embodiments, the digital wallet system may request
authority from a user to proceed with the automated transactions
before executing the automated transactions. In embodiments, the
digital wallet system may require receipt of a user's authorization
before performing a transaction by at least one of telephone
dialing a number and entering specified digits, text message,
email, or via a computer application or a user's mobile wallet. In
embodiments, the digital wallet system will automatically perform
the transaction if no response is received within a predetermined
amount of time set by a user in advance or by default.
[0765] The digital asset exchange computer system may also include
a fraud analysis system configured to detect fraudulent and/or
unauthorized transactions.
[0766] In embodiments, the digital math-based asset is bitcoin. In
embodiments, the digital math-based asset is based on a
mathematical protocol for proof of work. The mathematical protocol
may be open source. In embodiments, the mathematical protocol
includes a one-way cryptographic algorithm. In embodiments, the
mathematical protocol includes a sequential hard memory function.
The digital math-based asset may be based on a mathematical
protocol for proof of stake and is open source. In embodiments, the
digital math-based asset is based on a cryptographic mathematical
protocol. The digital math-based asset may be based on a
mathematical protocol for a hybrid of proof of work and proof of
stake. The digital math-based asset may be based on a mathematical
protocol for proof of stake velocity. The mathematical protocol may
rely upon ownership of respective digital math-based asset as a
function of duration of ownership. The digital math-based asset may
be based on a mathematical protocol for proof of burn.
[0767] In embodiments, a number of digital math-based assets in the
decentralized digital assert network is limited. In embodiments, a
number of digital math-based assets in the decentralized digital
assert network is not limited. A specified number of digital
math-based assets in the decentralized digital asset network may be
added into circulation during a defined time period.
[0768] In embodiments, the digital wallet is activated by a private
key, which is mathematically related to a public address in a
one-way function. In embodiments, the digital wallet includes a
multi-signature account which requires a plurality of private keys
to access the digital assets held by the multi-signature account.
In embodiments, more keys are generated for the multi-signature
account than are required to access and/or use an account.
[0769] In embodiments, an accounting computer 25 may be a hardware
security module, which may comprise hardware (e.g., one or more
processors, computer-readable memory, communications portals,
and/or input devices, to name a few) and/or software (e.g.,
software code designed to verify transactions, flag potentially
erroneous transactions, and/or stop potentially erroneous or
unauthorized transactions). Such a device may verify spending
transactions before the transactions are executed. A hardware
security module may flag transactions for review (e.g., by portal
administrators), before the transactions may be confirmed. A
hardware security module may be an offline device, which may be
given a daily account activity log (e.g., a log of exchange
withdrawals, deposits, exchange transactions (e.g., purchases and
sales), purchase order receipts, and/or sell order receipts, to
name a few) to determine whether proposed transactions,
particularly spending transactions, are valid. A protocol for
identifying owners of a digital wallet may be used to verify that
spending transactions will deliver the correct amount of assets to
the correct address. In embodiments, a quorum of a specified size
may be required to override a hardware security module. In
embodiments, a transaction may be processed using both an isolated
and a networked computer, as discussed herein. Such a transaction
may be performed using an air-gapped digital wallet, such as
described in the context of FIG. 36D, and isolated wallet computer
30' within faraday cage 50 or the isolated transaction computer 32
in faraday cage 60 which are air gapped from network computer 20.
In embodiments, an unsigned transaction may be performed on a
networked computer, which may only contain one or more wallets
capable of watching transactions and/or performing unsigned
transactions. A non-networked, isolated computer may contain one or
more complete wallets, which may be used to sign transactions. The
transaction may be transferred to the isolated computer for
signing. Hence, an air gap or other lack of a required
communication connection may exist between the isolated and
networked computer. In embodiments, the unsigned transaction data
may be transferred manually, such as by saving the data from the
networked computer to a removable storage medium (e.g., a USB flash
drive, CD, CD-ROM, DVD, removable hard drive, disk, memory card, to
name a few), and inputting or otherwise operatively connecting the
storage medium to the isolated computer. The isolated computer may
then access and sign the transaction data. The signed transaction
data may then be transferred back to the networked computer using
the same or different method of transfer as used for the unsigned
transaction data. The networked computer may then access and
upload, distribute, or otherwise act on the signed transaction data
to complete the transaction. In embodiments, the isolated computer
may generate and sign (e.g., with a private key) transaction
instructions, which may then be transferred to the networked
computer for distribution to the digital asset network. In
embodiments, the networked computer and the isolated computer may
be operatively connected, e.g., using a wired connection (e.g., a
USB cable, Ethernet cable, Laplink cable, to name a few) or using a
wireless connection (e.g., Bluetooth, Wi-Fi, infrared, radio, to
name a few). Such operative connection may replace the manual
transfer of transaction data between the computers, and in
embodiments, security measures, such as firewalls or automated
separable physical connector devices (e.g., controlled from the
isolated computer), may be employed to protect against unauthorized
access, particularly to the isolated computer. "Air gap, air wall
or air gapping" is a network security measure employed on one or
more computers to ensure that a secure computer network is
physically isolated from unsecured networks, such as the public
Internet or an unsecured local area network. The name arises from
the technique of creating a network that is physically separated
(with a conceptual air gap) from all other networks. To prevent
unauthorized data extrusion through electromagnetic or electronic
exploits, there is often a specified amount of space between the
air gapped system and outside walls and between its wires and the
wires for other technical equipment. For a system with extremely
sensitive data (such as a private key of a digital asset account),
as explained previously, a Faraday cage can be used to prevent
electromagnetic radiation (EMR) escaping from the air-gapped
equipment.
[0770] FIG. 32A illustrates an exemplary embodiment of a process
for creating digital wallets and storing their keys. In step SO2
one or more digital wallets may be created using one or more
isolated wallet computers 30'. In step SO4, the public and private
keys associated with the created digital wallets may be obtained
using one or more isolated wallet computers 30'. In embodiments,
referring to FIG. 32B, In step S05 each private key may be
ciphered. In step S06, each private key, which may be a ciphered
private key following step S05, may be divided into segments. In
step S08, one or more duplicate copies of each private key segment
may be created. In some embodiments, the private key may be divided
into 2, 3, 4 or more segments. In embodiments, each private key
segment may be encrypted or otherwise encoded In step S10. In
embodiments, steps S08 and/or S10 may be skipped. In step S12, each
private key segment may be associated with a reference number,
correlating the private key segment to the respective public key
and/or indicating the order of the private key segment within the
complete key. In step S14, each encrypted private key segment may
be converted to a storable medium, such as by printing each private
key segment on paper. In step S16, the private key segment as
converted in the storable medium (e.g., printed) is verified to
confirm it was properly and retrievable stored. In embodiments,
this step may be skipped. In step S18, each private key segment is
stored along with its reference number at one or more secure
locations. In step S20, each digital wallet is deleted, leaving the
stored keys as a means to regenerate the wallets.
[0771] FIG. 33A is a flow chart of a process for generating digital
asset accounts and securely storing the keys corresponding to each
account. In embodiments, the process may be performed using one or
more isolated computers not connected to any external data
networks. The isolated computer may comprise a clean copy of an
operating system (e.g., a clean boot) stored in computer-readable
memory and running on one or more processors.
[0772] In step S6002, a computer system comprising one or more
computers may be used to generate one or more digital asset
accounts capable of holding one or more digital math-based assets.
In embodiments, such accounts may be associated with digital asset
ownership and/or possession without physically holding a digital
asset in any location. A digital asset software client, which may
comprise part of a digital wallet or may be accessed using a
digital wallet, may be used to generate the digital asset
accounts.
[0773] In step S6004, the computer system may be used to obtain one
or more private keys corresponding to the one or more digital asset
accounts. In embodiments, the private keys may be generated as part
of the digital asset account creation process.
[0774] In step S6006, the computer system may be used to divide
each of the one or more private keys into a plurality of private
key segments. In embodiments, such as with a multi-signature
wallet, at least one private key for each digital asset account may
be divided into private key segments.
[0775] In step S6008, the one or more computers may be used to
encrypt each of the plurality of private key segments. Encryption
can comprise any of the techniques described herein, such as
character substitution, scrambling, mapping, and/or hashing, to
name a few. The computer system can apply one or more algorithms to
perform the encryption. Symmetric and or asymmetric encryption
algorithms may be applied.
[0776] In step S6010, the one or more computers may be used to
generate and/or associate each of the plurality of private key
segments with a respective reference identifier. A reference
identifier may be a number, alphanumeric sequence, or other unique
sequence that can be used to identify key segments, which may be
used for storage and/or retrieval of key segments. The reference
identifier for each key segment may be stored on a reference
identifier master list, which may be stored electronically and/or
on a physical substrate. The reference identifier master list may
associate with each other the reference identifiers for key
segments corresponding to the same key, and/or may also associate a
digital asset account identifier (e.g., a public key or public
address) with the key segments.
[0777] In step S6012, the one or more computers may be used to
create one or more cards for each of the encrypted plurality of
private key segments. Each card may have fixed thereon one of the
encrypted plurality of private key segments along with the
respective associated reference identifier. The cards may be paper,
such as index cards, 81/2 in..times.11 in. sheets of paper, or
other paper products. In other embodiments, the cards may include
plastic or metal. The cards may be laminated. A writing device may
fix the key segments and reference identifiers to the cards by
techniques such as printing, etching, and/or magnetically encoding,
to name a few. A scanable code, such as a bar code or QR code, may
be used to write the keys to the cards.
[0778] In embodiments, collated sets of cards may be produced for a
plurality of digital asset accounts. Each set may contain only one
card per private key such that the private key segments for a
single private key are divided among different sets of cards.
[0779] In embodiments, following creation of the one or more cards,
quality control steps can be performed. A reading device may be
used to read each of the cards to ensure readability.
[0780] In step S6014, the one or more computers may be used to
track storage of each of the one or more cards in one or more
vaults. Vaults may be geographically remote. Vaults can include
bank vaults and/or precious metal vaults. In embodiments, a main
set of vaults and one or more sets of backup vaults may be used. A
main set of vaults can be located in a geographically proximate
area, such as a metropolitan area of a city, while backup sets of
vaults may be located in geographically remote areas. The backup
vaults may contain duplicate copies of the cards. Vault locations
for each card or set of cards may be included on the reference
identifier master list.
[0781] In embodiments, the process can further include receiving at
the computer system a quantity of digital math-based assets, and
storing those digital assets in the one or more securely stored
digital asset accounts. In embodiments, storing the digital asset
can comprise transferring the digital assets into accounts with
securely stored private keys. Accordingly, storing can comprise
generating electronic transfer instructions for an electronic
transfer of the quantity of digital math-based assets to the one or
more digital asset accounts and broadcasting the electronic
transfer instructions to a decentralized electronic ledger
maintained by a plurality of physically remote computer
systems.
[0782] FIG. 33B is a flow chart of another exemplary process for
generating digital asset accounts and securely storing the keys
corresponding to each account.
[0783] In step S6022, a computer system comprising one or more
computers may be used to generate one or more digital asset
accounts capable of holding one or more digital math-based assets,
as described with respect to step S6002 of FIG. 6A.
[0784] In step S6024, the computer system may be used to obtain one
or more private keys corresponding to the one or more digital asset
accounts, as described with respect to step S6004 of FIG. 6A.
[0785] In step S6026, the computer system may be used to encrypt
each of the one or more private keys.
[0786] After encryption, In step S6028, the computer system may be
used to divide each of the encrypted private keys into a plurality
of key segments.
[0787] In step S6030, the one or more computers may be used to
generate and/or associate each of the plurality of private key
segments with a respective reference identifier.
[0788] In step S6032, the one or more computers may be used to
create one or more cards for each of the plurality of private key
segments.
[0789] In step S6034, the one or more computers may be used to
track storage of each of the one or more cards in one or more
vaults.
[0790] FIG. 33C is a flow chart of another exemplary process for
generating digital asset accounts and securely storing the keys
corresponding to each account. The exemplary process may generate
and store keys for, a multi-signature digital asset account, where
at least one of the private keys is divided into a plurality of key
segments.
[0791] In step S6042, a computer system comprising one or more
computers may be used to generate one or more digital asset
accounts capable of holding one or more digital math-based
assets.
[0792] In step S6044, the computer system may be used to obtain a
first plurality of private keys corresponding to each of the one or
more digital asset accounts. Each first plurality of private keys
can comprise the private keys of a multi-signature account.
[0793] In step 6046, the computer system may be used to divide a
first private key of the first plurality of private keys into a
second plurality of first private key segments. For a
multi-signature digital asset account at least one of the private
keys may be divided into private key segments.
[0794] In step S6048, the computer system may be used to encrypt
each of the second plurality of first private key segments. In
embodiments, the second key may be encrypted.
[0795] In step S6050, the computer system may be used to generate
and/or associate each of the second plurality of first private key
segments with a respective reference identifier.
[0796] In step S6052, the computer system may be used to create one
or more cards for each of the encrypted second plurality of first
private key segments wherein each of the one or more cards has
fixed thereon one of the encrypted second plurality of first
private key segments along with the respective associated reference
identifier. In embodiments, the second key may be written, e.g.
using the writing device, to one or more physical substrates, such
as paper, plastic, and/or metal. In other embodiments, the second
key may be stored electronically.
[0797] In step S6054, the computer system may be used to track
storage of each of the cards in one or more vaults, as well as to
track storage of the second private key. A reference identifier
master list may identify the storage locations of each key and key
segment.
[0798] FIG. 33D is a flow chart of an exemplary process for
securely generating digital asset accounts and storing associated
keys using a secure portal.
[0799] In step S6062, an electronic isolation chamber may be
provided containing one or more writing devices (e.g., printers,
engravers, magnetic card encoders, to name a few), one or more
reading devices (e.g., scanners, bar code scanners, QR readers,
magnetic card readers, to name a few), and an isolated computer
operatively connected to the one or more writing devices but not
directly connected to an external data network and comprising one
or more processors and computer-readable memory.
[0800] In step S6064, the isolated computer may be used to generate
a first plurality of digital asset accounts capable of holding one
or more digital math-based assets. In embodiments, the first
plurality of digital asset accounts may comprise multi-signature
digital asset accounts.
[0801] In step S6066, the isolated computer may be used to obtain
one or more private keys and a digital asset account identifier
corresponding to each of the first plurality of digital asset
accounts.
[0802] In step S6068, the isolated computer may be used to
associate each of the one or more digital asset accounts with a
respective reference identifier. The reference identifier may
comprise an alphanumeric sequence. In embodiments, respective
reference identifiers may be associated with one or more keys or
key segments corresponding to the respective digital asset
accounts.
[0803] In step S6070, the isolated computer may be used to divide
at least one of the one or more private keys corresponding to each
of the first plurality of digital asset accounts into a second
plurality of private key segments. In embodiments, each private key
segment may be required to regenerate the respective private key.
In embodiments, a subset of the second plurality of private key
segments (e.g., 3 of 5 keys) could be sufficient to regenerate the
respective private key.
[0804] In step S6072, the isolated computer may transmit to the one
or more writing devices, electronic writing instructions for
writing each of the second plurality of private key segments and
the respective reference identifier on a respective card to
generate a third plurality of collated sets of cards wherein each
of the collated sets of cards comprises cards corresponding to
different private keys. In embodiments, the third plurality of
collated sets can include one or more duplicate sets for each of
the collated sets of cards. In embodiments, the isolated computer
may be used to generate the electronic writing instructions prior
to transmitting them to the one or more writing devices.
[0805] In step S6074, the one or more writing devices may be used
to write each respective private key segment of the second
plurality of private key segments and the respective reference
identifier on a respective card according to the electronic writing
instructions. In embodiments, step S6074 can comprise printing
and/or etching each respective private key segment of the plurality
of private key segments and the respective reference identifier on
respective separate cards. In embodiments, each respective private
key segment of the plurality of private key segments may be
magnetically encoded on respective separate cards. The respective
reference identifiers may be printed on the respective cards, e.g.,
to be readable without a magnetic card reader. Each respective
private key segment of the second plurality of private key segments
may be written, e.g., printed, as a scanable code, such as a bar
code and/or a QR code.
[0806] In step S6076, the isolated computer may be used to write
each of the digital asset account identifiers along with the
corresponding reference identifier. In embodiments, step S6076 can
further comprise the steps of transmitting, from the isolated
computer to the one or more writing devices, second electronic
writing instructions for writing each of the digital asset account
identifiers along with the corresponding reference identifier, and
writing, using the one or more writing devices, each of the digital
asset account identifiers along with the corresponding reference
identifier according to the second writing instructions. In
embodiments, writing according to the second writing instructions
can comprise writing to an electronic storage medium, such as a
flash drive, hard drive, and/or disc. In embodiments, the
electronic storage medium could include a hardware storage module
("HSM"). In embodiments, writing according to the second writing
instructions can comprise writing to a physical storage medium,
such as paper.
[0807] In step S6078, the one or more reading devices may be used
to read each of the cards to ensure readability. In embodiments,
step S6078 may be performed after step S6076. In embodiments, step
S6078 may be performed before step S6076.
[0808] In embodiments, the process illustrated by FIG. 33D can
further comprise the step of writing, using the isolated computer,
the respective digital asset account identifiers to a removable
electronic storage medium, e.g., for transfer to an accounting
computer.
[0809] In embodiments, the process can further comprise the step of
destroying the isolated computer, the one or more writing devices,
and the one or more reading devices, or destroying any one of those
devices.
[0810] In embodiments, the method can further comprise the step of
encrypting, using the isolated computer, each of the second
plurality of private key segments. In embodiments, encryption
techniques can include symmetric-key encryption, asymmetric-key
encryption, scrambling, substitution, hashing, or adding
characters.
[0811] In embodiments, the method can further comprise the step of
tracking, using the isolated computer, storage of each of the third
plurality of collated sets of cards. In embodiments, each of the
third plurality of collated sets of cards may be stored in a vault.
In embodiments, each collated set of cards may be stored in a
separate vault.
[0812] FIGS. 29B and 29C illustrate exemplary embodiments of the
present invention where one or more computers 25 running accounting
software to account for the assets and/or expenses of an account
holder can be located either within the secure location 10 (e.g.,
FIG. 29B) or outside of the secure location 10 (e.g., FIG. 29C). In
embodiments, such accounting software as well as possibly other
software may be stored, accessed and/or operated on one or more
networked computers 20 in the secure location 10. In embodiments,
the accounting computer 25 may be the same or different from
isolated computer 30 and/or networked computer 20 and/or a mining
computer.
[0813] In embodiments, an accounting computer 25 may be a hardware
security module, which may comprise hardware (e.g., one or more
processors, computer-readable memory, communications portals,
and/or input devices, to name a few) and/or software (e.g.,
software code designed to verify transactions, flag potentially
erroneous transactions, and/or stop potentially erroneous or
unauthorized transactions). Such a device may verify spending
transactions before the transactions are executed. A hardware
security module may flag transactions for review (e.g., by portal
administrators), before the transactions may be confirmed. A
hardware security module may be an offline device, which may be
given a daily account activity log (e.g., a log of ETP redemptions
and/or creations) to determine whether proposed transactions,
particularly spending transactions, are valid. A protocol for
identifying owners of a digital wallet may be used to verify that
spending transactions will deliver the correct amount of assets to
the correct address. In embodiments, a quorum of a specified size
may be required to override a hardware security module. In
embodiments, a transaction may be processed using both an isolated
and a networked computer, as discussed herein. Such a transaction
may be performed using an air-gapped digital wallet, such as
described in the context of FIG. 29D, and isolated wallet computer
30' within faraday cage 50 or the isolated transaction computer 32
in faraday cage 60 which are air gapped from network computer 20.
In embodiments, an unsigned transaction may be performed on a
networked computer, which may only contain one or more wallets
capable of watching transactions and/or performing unsigned
transactions. A non-networked, isolated computer may contain one or
more complete wallets, which may be used to sign transactions. The
transaction may be transferred to the isolated computer for
signing. Hence, an air gap or other lack of a required
communication connection may exist between the isolated and
networked computer. In embodiments, the unsigned transaction data
may be transferred manually, such as by saving the data from the
networked computer to a removable storage medium (e.g., a USB flash
drive, CD, CD-ROM, DVD, removable hard drive, disk, memory card, to
name a few), and inputting or otherwise operatively connecting the
storage medium to the isolated computer. The isolated computer may
then access and sign the transaction data. The signed transaction
data may then be transferred back to the networked computer using
the same or different method of transfer as used for the unsigned
transaction data. The networked computer may then access and
upload, distribute, or otherwise act on the signed transaction data
to complete the transaction. In embodiments, the isolated computer
may generate and sign (e.g., with a private key) transaction
instructions, which may then be transferred to the networked
computer for distribution to the digital asset network. In
embodiments, the networked computer and the isolated computer may
be operatively connected, e.g., using a wired connection (e.g., a
USB cable, Ethernet cable, Laplink cable, to name a few) or using a
wireless connection (e.g., Bluetooth, Wi-Fi, infrared, radio, to
name a few). Such operative connection may replace the manual
transfer of transaction data between the computers, and in
embodiments, security measures, such as firewalls or automated
separable physical connector devices (e.g., controlled from the
isolated computer), may be employed to protect against unauthorized
access, particularly to the isolated computer.
[0814] FIG. 34 is a flow chart of a process for retrieving securely
stored private keys in accordance with exemplary embodiments of the
present invention.
[0815] In exemplary embodiments, in step S702, a computer system
comprising one or more computers may be used to determine one or
more digital asset account identifiers corresponding to one or more
digital asset accounts capable of holding one or more digital
math-based assets.
[0816] In step S704, the computer system may be used to access key
storage information associated with each of the one or more digital
asset account identifiers. In embodiments, the key storage
information may comprise a reference identifier associated with one
or more stored private key segments.
[0817] In step 706, the computer system may be used to determine,
based upon the key storage information, storage locations
corresponding to each of a plurality of private key segments
corresponding to each of the one or more digital asset
accounts.
[0818] In step 708, retrieval instructions for retrieving each of
the plurality of private key segments may be issued or caused to be
issued.
[0819] In step 710, each of the plurality of private key segments
may be received at the computer system.
[0820] In step 712, the computer system may be used to decrypt each
of the plurality of private key segments.
[0821] In step 714, the computer system may be used to assemble
each of the plurality of private key segments into one or more
private keys.
[0822] In embodiments, the process depicted in FIG. 34 may further
comprise the step of accessing, using the computer system, the one
or more digital asset accounts associated with the one or more
private keys. In further embodiments, the process depicted in FIG.
34 may further comprise the steps of accessing, using an isolated
computer of the computer system, wherein the isolated computer is
not directly connected to an external data network, the one or more
digital asset accounts associated with the one or more private
keys; generating, using the isolated computer, transaction
instructions comprising one or more transfers from the one or more
digital asset accounts; transferring the transaction instructions
to a networked computer of the computer system; and broadcasting,
using the networked computer, the transaction instructions to a
decentralized electronic ledger maintained by a plurality of
physically remote computer systems.
[0823] FIG. 35 describes an exemplary method of performing secure
transactions. In step S702, a digital wallet may be created on an
isolated computer. In step S704, a watching copy of the digital
wallet, which may not include any private keys, may be created on
the isolated computer. In step S706, the watching copy of the
digital wallet may be transferred from the isolated computer to a
networked computer. In step S708, an unsigned transaction may be
created using the watching copy of the wallet on the networked
computer. In step S710, data associated with the unsigned
transaction may be transferred from the networked computer to the
isolated computer. In step S712, the unsigned transaction data may
be signed using the digital wallet on the isolated computer. In
step S714, the signed transaction data may be transferred from the
isolated computer to the networked computer. In step S716, the
signed transaction data may be broadcast, using the watching copy
of the wallet on the networked computer, to a digital asset
network. In embodiments, the broadcast of a signed transaction may
complete a transaction and/or initiate a verification process that
may be performed by the network.
[0824] In embodiments, processes for generating digital asset
accounts and/or storing associated keys may be performed by a
secure system, e.g., an administrative portal. The system can
comprise an electronic isolation chamber, such as a Faraday cage.
The system can further comprise one or more isolated computers
within the electronic isolation chamber and comprising one or more
processors and computer-readable memory operatively connected to
the one or more processors and having stored thereon instructions
for carrying out the steps of (i) generating, using the one or more
isolated computers, one or more digital asset accounts capable of
holding one or more digital math-based assets; (ii) obtaining,
using the one or more isolated computers, one or more private keys
corresponding to the one or more digital asset accounts; (iii)
dividing, using the one or more isolated computers, at least one of
the one or more private keys for each digital asset account into a
plurality of private key segments, wherein each private key segment
will be stored; (iv) associating, using the one or more isolated
computers, each of the plurality of private key segments with a
respective reference identifier; and (v) transmitting, from the one
or more isolated computers to one or more writing devices
operatively connected to the one or more isolated computers,
electronic writing instructions for writing a plurality of cards,
collated into a plurality of sets having only one private key
segment per digital asset account, and each card containing one of
the plurality of private key segments along with the respective
associated reference identifier. The system can further comprise
one or more writing devices located within the electronic isolation
chamber and configured to perform the electronic writing
instructions, including collating the plurality of cards into the
plurality of sets. The system can also comprise one or more reading
devices located within the electronic isolation chamber and
configured to read the plurality of private key segments along with
the respective associated reference identifier from the one or more
cards. The reading devices may be used for quality control, to
ensure that the cards are readable.
Cold Storage
[0825] In embodiments, a digital asset account holder may operate
one or more computers to manage, process, and/or store the
transactions and/or digital assets. In embodiments, a portion,
consisting of some or all, of the digital assets may be stored in
cold storage, which involves no outside connections. Cold storage
may be a bank vault, a precious metal vault, a lockbox, or some
other secure room or area. There may be no communication channels
connecting to the cold storage area. In embodiments, electronic
vaults may be used. Electronic vaults may comprise cloud storage,
one or more hard drives, flash drives, memory cards or like storage
technology, to name a few. Electronic vaults may hold one or more
keys and/or key segments, which may be encrypted and/or encoded as
described herein.
[0826] In embodiments, the cold storage may comprise a divided
storage system. In a divided storage system, components or portions
of components may be stored at multiple locations. Components may
be at least digital wallets, public and/or private keys, or
assets.
[0827] FIG. 31A is a schematic diagram of a cold storage vault
system in accordance with exemplary embodiments of the present
invention. In embodiments, each private key to be stored in vaults
70 for cold storage may be divided into one or more segments 80. In
embodiments, each segment can be stored in a separate vault 70. In
this manner, the risk of each of the segments 80 being reassembled
into a complete key may be reduced due to the segregation of each
piece of each key. Each vault may then be located at different
locations, e.g., Locations A, B, and C. In embodiments, each vault
(e.g., 70-Aa, 70-A2, 70-A3) may be located at different locations
in the same general vicinity (e.g., the general vicinity of
Location A, which may be New York City). Each vault may have a user
entry log to provide a record of access to the vault and/or may
employ security measures to ensure only authorized access.
[0828] Duplicate sets of the segmented private keys may then be
made and stored in separate vaults (e.g., one duplicate copy
divided between Vaults 70-B1, 70-B2, and 70-B3, and another
duplicate copy divide between Vaults 70-C1, 70-C2, and 70-C3). Each
set of segmented keys 80 may be located in the same general
vicinity (e.g., Location B for Vaults 70-B1, 70-B2, and 70-B3 and
Location C for Vaults 70-C1, 70-C2, and 70-C3), with each general
vicinity being different from other general vicinities (e.g.,
Location B may be Philadelphia, Pennsylvania and Location C may be
Indianapolis, Indiana). Locations may include domestic and/or
international locations. Locations can be selected based on at
least one or more of the following parameters: ease of access,
level of security, diversity of geographic risk, diversity of
security/terror risk, diversity of available security measures,
location of suitable vaults in existence (e.g., custodian vaults
for a trust associated with an ETP), space available at vaults,
jurisdictional concerns, to name a few. In embodiments, three
geographic locations can be used wherein Location A is within a
short intraday time of transit (e.g., 1 hour), Location B is within
a longer intraday time of transit (e.g., 3-4 hours), and Location C
is within one or more day times of transit (e.g., 1-2 days). In
embodiments, the location of the vaults may be within a distance
that allows segments of key pairs to be retrieved within a
redemption waiting period (e.g., 3 days). A complete key set (e.g.,
stored private keys parts 1-3) may be stored in each vault general
location (e.g., Location A, Location B, Location C).
[0829] In FIG. 31A, three segments have been used, but other
numbers of segments can also be used consistent with embodiments of
the present inventions. FIG. 31B illustrates that any number of
vault general locations (e.g., A-N) may be used, which may entail N
number of complete key sets. In embodiments, the keys may be broken
into any number of key segments, 1-N. In embodiments, in order to
reassemble one complete key, all N segments may have to be
reassembled together.
[0830] In embodiments, there may be two sets of segmented keys, as
illustrated in FIG. 31C, which may be located in two general
locations (e.g., A and B). In embodiments, the keys may be parsed
into two segments (e.g., 80-1 and 80-2), as illustrated in FIG.
31C.
[0831] In embodiments, duplicate sets may not be embodied in same
form as the original set and/or other duplicate sets. For example,
two sets may be stored on paper, and a third set is stored on
papyrus. In embodiments, at least one set of segmented keys can be
stored on paper, while at least one set is stored on one or more
disks, memory sticks, memory cards, tapes, hard drives, or other
computer readable media. In embodiments, the same number of
segments can be used for each set. In embodiments, a different
number of segments can be used for at least two of the sets (e.g.,
3 segments for 1 set, and 4 segments for 1 set). In embodiments,
different types of coding and/or encryption can be used for at
least two sets. FIG. 31D illustrates three sets of key copies,
where the third copy 80 stored in vault 70-C may not be divided
into segments. Such a key copy may be encrypted like any of the
other key segments.
[0832] A cold storage back-up may be provided by a one-way
electronic data recordation system. The system can function as a
write-only ledger. Upon deposit of digital assets into cold
storage, the corresponding private keys may be transmitted to the
recordation system, which will store a record of the transaction.
When digital assets are removed from a wallet, a record of the
removal and/or wallet destruction can be sent to the system. In the
event that wallet keys must be retrieved, the recordation system
can be accessed to determine the wallet keys. Accessing the
recordation system to retrieve keys can be designed to be a
difficult operation, only to be performed in the event of an
emergency need to recover wallet keys.
Key Storage Service
[0833] Digital asset storage services and/or digital asset
protection may be provided in accordance with the present
invention. Digital asset storage may use any of the secure storage
systems and methods described herein. In embodiments, a digital
asset storage service may be provided to other entities (e.g., a
trust, authorized participants in the trust, retailers, banks, or
other digital asset users), to provide secure storage of digital
assets. Such a storage service may use any of the security measures
described herein. In embodiments, a digital asset storage service
may comprise, form a part of, and/or be associated with a digital
asset insurance system, as described herein.
[0834] Digital asset protection can be digital asset insurance
and/or digital asset warranties. Digital asset insurance may be
insured key storage, which may entail secure storage of one or more
keys, such as private keys, where the secure storage service may
guarantee the return of the stored private key and will pay out
some amount if the key cannot be returned. In embodiments, a
digital asset warranty can be a warranty against key loss, which
may be a warranty against key loss by a digital asset storage
service.
[0835] A digital asset storage service and/or a digital asset
protection system may be associated with and/or accessed through
one or more digital wallets. In embodiments, digital asset
protection and/or storage services may only be available when using
a particular digital asset wallet and/or when employing particular
storage mechanisms or procedures. In embodiments, a digital wallet
may provide an option to request and/or accept protection and/or an
option to request and/or accept storage of one or more keys
associated with the wallet. In embodiments, a wallet may prompt
and/or require a user to store the private key of the wallet, e.g.,
using the secure digital asset storage service.
[0836] FIG. 36A illustrates an exemplary system for providing
secure digital asset storage and/or protection. A storage computer
system 3320 may store in computer-readable media or otherwise be
connected to one or more databases containing data 3335 relating to
one or more digital asset or key storage policies. In embodiments,
data 3335 can also include information relating to a stored or
insured digital wallet, such as public keys, public addresses,
and/or key storage information, which may comprise identification
codes or other indicators of where keys or key segments are stored.
The storage computer system 3320 may store key data 3325 in
internal or external computer-readable memory comprising one or
more databases. Key data 3325 can include public key data,
information identifying a key owner or wallet owner, information
(e.g., an identifying code) identifying or correlating a wallet's
keys or key segments, and/or information identifying location
and/or retrieval information for stored keys or key segments, to
name a few.
[0837] The exemplary system illustrated in FIG. 36A can include a
plurality of secure storage locations, such as vaults 3305-1,
3305-2, and 3305-3. Private keys or key segments 3310-1, 3310-2,
and 3310-3 may be stored in each vault in accordance with the
secure storage systems and methods discussed herein, such as cold
storage vaulting in different locations. Vaults may be connected to
a network 15 at times and disconnected at other times. The network
15 may be any data network or a plurality of connected networks,
internal, such as an intranet, or external, such as the Internet. A
plurality of keys corresponding to a multi-key wallet may be stored
in separate vaults. In embodiments, one or more keys may be divided
into segments, which can be stored in separate vaults. Keys may be
divided whether from single private key wallets or multi-key
wallets.
[0838] One or more users 3315 may be, e.g., customers and/or
claimants of a digital asset storage and/or protection system.
Users 3315 may obtain key storage for one or more digital wallets
containing digital assets in one or more denominations. Users 3315
may access or otherwise participate in a digital asset storage
and/or protection system using one or more user device. In
embodiments, the same digital wallet may be accessed from a
plurality of user devices using the same key combinations (e.g.,
private and public keys).
[0839] FIG. 36B shows another exemplary embodiment of a system for
providing secure digital asset storage and/or protection. A
plurality of vaults 3305-1 to 3305-N may be employed to store keys
or key segments in segregated locations. In embodiments, vaults may
be secure locations, such as safety deposit boxes, bank vaults,
rooms with controlled access, to name a few. Vaults may be physical
and/or electronic repositories for keys or key segments. In
addition, each vault may have one or more backups 3355 (e.g., Q
number of backups for vault 3305-1, R number of backups for vault
3305-2, and S number of backups for vault 3305-N). Vault backups
may be other vaults or other secure storage facilities, units, or
devices. Vault backups may utilize the same or different types of
storage from each other and/or from the primary vault. For example,
a primary vault may include printed paper copies of keys or key
segments stored in a bank lockbox, while a backup may comprise an
offline encrypted hard drive storing data corresponding to keys or
key segments. Vault backups 3355 can be any of physical storage of
printed or transcribed keys or key segments, remote cloud storage,
hard drive, disk, CD, DVD, memory card, flash drive, tape drive,
and/or tape library, to name a few.
Storage of Keys by a Digital Asset Storage Service
[0840] As discussed herein, a digital asset storage service may be
provided to users of a digital asset network to provide secure
storage of digital assets. In embodiments, the secure storage
service may be used in conjunction with a digital asset protection
plan, such as an insurance or warranty plan, although the storage
service may also be used without insurance or warranties. FIGS.
37A-37B describe exemplary processes for storing private keys,
which may be used solely as a key storage service or in conjunction
with protection plans, such as insurance or warranty plans.
[0841] In embodiments, a user of a digital asset network may
provide one or more keys or key segments to the key storage service
for storage. Keys or key segments may be provided to the storage
service via email or other electronic data transfer, any of which
may be secure or otherwise encrypted. A user may use software to
generate a wallet with one or more private keys and/or to divide
the keys into segments. The software may include the ability to
transmit, e.g., via a secure connection, the keys or key segments
to the secure storage company. In embodiments, keys may be
delivered to a key storage company in person, via mail, or via fax.
Such keys may be stored in accordance with the secure and cold
storage vault security mechanisms discussed herein, which may
include dividing the keys into segments if not already divided.
[0842] Keys may also be generated at the secure storage company,
e.g., at the secure storage site. Accordingly, a user may log into
a website or otherwise connect to a portal for accessing wallet
generation software. Such software may be running on one or more
processors located at the secure storage company. The user may use
the wallet generation software to create a wallet with one or more
private keys. The user may also use such software to split one or
more keys into key segments. Each key or key segment may then be
printed, transcribed, or otherwise prepared for storage. In
embodiments, the software may be programmed to transmit each key or
key segment to a different printer, printing device, or electronic
storage device, any of which may be located in different rooms, on
different premises, in different geographies, and/or in separate
vaults, to name a few. Thus, the key storage service may then store
each key or key segment in separate locations, in accordance with
the secure storage mechanisms discussed herein, such as the cold
storage vault systems. Accordingly, the key storage company may
never have access to an assembled key or to the required plurality
of keys to a multi-key wallet.
[0843] Upon a user's request for retrieval of a stored key or keys,
the secure key storage company may send to the user originals or
copies, physically or electronically, of the keys or key segments.
In embodiments, the key storage company may never reassemble keys
or access a digital wallet itself. The secure key storage company
may charge fees at setup and/or at retrieval, as well as recurring
storage fees.
[0844] FIG. 37A describes an exemplary embodiment of a process for
secure key storage and arranging for insurance or warranties
against lost private keys, which process may be performed using a
digital asset storage system, as discussed herein. The digital
asset storage system may comprise and/or form a part of a digital
asset protection system. FIG. 37A refers to the storage of private
keys, but the process may apply to the storage of both private and
public keys.
[0845] FIG. 37A is a flow chart of an exemplary process for
securely storing private key information, which may be performed by
a secure digital asset storage system. In step S3422, a request to
store a private key may be received at the secure digital asset
storage system. In embodiments, such a request may comprise a
request for insured private key storage. Such a request may
originate from one or more other computers or electronic devices,
such as a mobile phone, digital asset transaction kiosk, and/or
personal computer, to name a few.
[0846] In step S3424, a user may provide identification
information, which may be received at the storage system
Identification information may comprise any of a name, contact
information (e.g., address, telephone number, e-mail address, to
name a few), government ID information (e.g., an image of a
driver's license, a driver's license ID number, a passport number,
to name a few), biometric information (e.g., a voice sample,
current photograph, eye scan, fingerprint, to name a few),
username, password, and/or one or more security questions, to name
a few. The identification information may be provided by and/or
correspond to the requestor of private key storage and/or the
private key owner. In embodiments, the digital asset insurance
system may receive and/or store a user's identification
information.
[0847] In step S3426, the storage system may obtain a private key
to be stored. The storage system may receive the key or fetch it,
e.g., from a user electronic device, such as a mobile phone. In
embodiments, the storage system may also obtain a public key to be
stored.
[0848] In step S3428, the storage system may cipher the private
key, as described herein. In embodiments, the private key may not
be ciphered before dividing it into segments. In other embodiments,
the private key may be encrypted.
[0849] In step S3430, the digital asset storage system may divide
the ciphered private key into any number of segments. In the case
of a multi-key wallet, the keys may not be divided into segments.
However, keys to a multi-key wallet may be encrypted and/or
ciphered.
[0850] In step S3432, the storage system may encrypt each private
key segment. In embodiments, encryption and/or ciphering may occur
only before or only after dividing a key into segments. In
embodiments, the key segments may not be encrypted after the
segments are created. The key segments may be ciphered or not
processed further.
[0851] In step S3434, the storage system may transfer each
encrypted private key segment to a different electronic vault for
storage. In embodiments, the vaults may not be electronic, and the
key segments may be printed or otherwise transcribed on a physical
substrate and stored in the vaults. Any number of vaults may be
used (e.g., one vault for each key segment, multiple vaults for
redundant copies of each key segment, one or more vaults with two
or more key segments stored together, to name a few). A code, such
as a bar code or QR code, may be provided along with the key
segments (e.g., printed with a physically transcribed copy of a key
segment electronically saved with an electronic key segment, or
appended to an electronic key segment, to name a few). The code may
identify the key segments (e.g., which key segments are part of the
same key) and/or the order of the key segments.
[0852] In step S3436, the storage system may store, in one or more
databases, key storage plan information (e.g., a subscription for
key storage costing $1.99/month), user identification information,
private key segment vault location information, and decryption and
deciphering instructions. The databases may be computer-readable
databases or physical (e.g., paper) databases that may be scanned
and then read by one or more computers. In embodiments, the stored
information may be sent to a user and/or an storage system
administrative coordinator, which may be a computer that can handle
retrieval of stored keys.
[0853] In step S3438, the digital asset storage system may send
confirmation of private key storage (e.g., over a data transfer
network) to the user (e.g., requestor of private key storage or
other person associated with the received identification
information) and/or a third party. Confirmation of storage may be
recorded by the storage system and/or another entity associated
with the storage system.
[0854] FIG. 37B illustrates that physical back-ups of the secured
private key may be employed by a secure digital asset storage
system. In step S3442, a request to store a private key may be
received at the storage system.
[0855] In step S3444, the storage system may receive user or
digital wallet owner account identification information.
[0856] In step S3446, the storage system may obtain (e.g., receive
or fetch) a private key.
[0857] In step S3448, the storage system may cipher the private
key. In embodiments, no ciphering may occur before dividing the key
into segments.
[0858] In step S3450, the storage system may divide the private key
(or ciphered private key) into segments.
[0859] In step S3452, the storage system may cipher each private
key segment.
[0860] In step S3454, the storage system may print each ciphered
private key segment. One or more copies of the key segments may be
printed and/or otherwise transcribed onto any substrate and/or
multiple substrates (e.g., paper, plastic, metal, to name a few). A
code, such as a QR code or bar code, may be used to identify
corresponding key segments and/or the order of the key segments.
Such a code may be printed or otherwise provided with the key
segments.
[0861] In step S3456, the digital asset storage system may store
each ciphered private key segment, as discussed herein. The key
segments may be stored in electronic vaults (e.g., hard drives,
tape drives, solid state memory, to name a few). Separate vaults
may be used for each key segment, although multiple key segments
corresponding to multiple different private keys may be stored in
the same vault.
[0862] In step S3458, the storage system may store each printed key
segment in a physical vault, which may be separate vaults for each
key segment.
[0863] In step S3460, the storage system may store, in one or more
databases, key storage plan information, user identification
information, private key segment vault location information,
deciphering instructions, and decryption instructions, where
applicable.
[0864] In step S3462, the storage system may send confirmation of
private key storage to the user.
Recovering Stored Keys from a Digital Asset Key Storage Service
[0865] A user of a secure storage service or system may request
access to a stored key, which may be a means of recovering a lost
key.
[0866] FIG. 38A is a flow chart describing an exemplary process for
recovering a key, which may be performed by one or more computers.
In embodiments, the process may entail recovering (e.g., retrieving
from storage) a plurality of keys or key segments.
[0867] In step S3502, a user may submit a claim for a lost private
key, which may be received by a computer system of a secure storage
service storing a copy of the user's private key. A claim may be a
request for retrieval of one or more stored keys.
[0868] In step S3504, the storage system, using the computer
system, may correlate the received claim to one or more locations
where private key segments are stored. For example, the computer
system may access a database of policy information to determine
where (e.g., in which vaults) a claimants keys or key segments are
stored.
[0869] In step S3506, a message, which may constitute instructions,
may be transmitted to one or more storage facilities to retrieve
the private key segments. A computer system may automatically
generate such a message based upon the information pertaining to
stored keys or key segments. Such a key retrieval message can
include a security code or other authorization to access a secure
storage location. In embodiments, the computer system may employ
security measures, such as a secure code or digital signature, to
provide verification and/or authentication of a retrieval
message.
[0870] In step S3508, the private key segments may be verified.
Keys or key segments may be retrieved from their respective storage
locations. Quality control measures may verify that the correct key
segments were retrieved and/or that the keys or key segments are
readable, e.g., by a specially programmed scanning device, such as
a QR scanner.
[0871] In step S3510, the private key segments may be transmitted
to a device and/or account corresponding to the user. One or more
secure transmissions may be used. Two-factor authentication may be
required of the recipient before a transmission is sent and/or
opened by the recipient. In embodiments, the system may decrypt,
reassemble, and/or decipher private keys and/or key segments before
returning the keys and/or key segments to a user. In embodiments, a
user may be provided with the option of having the system perform
the decrypting, reassembling, and/or deciphering steps. In
embodiments, software may be provided to a user to enable such
steps to be performed by a user or under a user's control. In
embodiments, the computer system may never decrypt keys or key
segments that were encrypted by a user. Accordingly, in step S3510,
the user may be provided with key segments and/or reassembled keys,
which may be in various states of security (e.g., ciphered,
segmented, and/or encrypted).
[0872] In step S3512, the system may receive confirmation that the
user received the private keys or key segments. A user device may
automatically generate and/or transmit a confirmation upon receipt
of the keys or key segments, upon reassembling thereof, upon
opening a corresponding digital asset wallet, or upon instruction
for a user, to name a few. Such confirmation may provide an
indication that the secure storage service and/or protection
service met its obligation, e.g., to the customer.
[0873] FIG. 38B illustrates another exemplary process for
recovering a key. Such process may be performed by one or more
computers. The process may be considered the same as the process of
FIG. 38A, except with the addition of a user authentication step
S3524.
[0874] Thus, In step S3522, a user may submit a claim for a lost
private key, which may be received by a secure storage service
storing a copy of the user's private key.
[0875] In step S3524, the secure storage system may authenticate
the identity of the claimant. Authentication may involve any of
receipt of any of a user's identification information, such as
name, username, password, biometric information, or the like. In
embodiments, three forms of identification information may be
required. In embodiments, a claimant may receive a phone call,
which may be auto-generated and auto-executed by the system, which
may provide the claimant with a code to input at a user device. In
embodiments, the user may be required to repeat a phrase, which may
be a unique phrase. Voice analysis and/or recognition techniques
may be employed. The user may be required to submit a current
picture or video. The system may compare the received
identification information to a database of authorized user
identification information in order to authenticate the identity of
the claimant.
[0876] In step S3526, the system may correlate the received claim
to one or more locations where private key segments may be
stored.
[0877] In step S3528, a message, which may constitute instructions,
may be transmitted to one or more storage facilities to retrieve
the private key segments.
[0878] In step S3530, the private key segments may be verified.
[0879] In step S3532, the private key segments may be transmitted
to a device and/or account corresponding to the user. In
embodiments, decryption, reassembly, and or deciphering of private
keys and/or key segments may occur before or after returning the
keys and/or key segments to a user and may be performed by the
system or by a user, who may use software provided by the
system.
[0880] In step S3534, the system may receive confirmation that the
user received the private key segments.
[0881] Another exemplary process for recovering a key is provided
in FIG. 38C. Such process may be performed by one or more
computers. The process may be considered the same as the process of
FIG. 38B, except with the addition of steps to check the account
balance of the account and a determination step of whether to
proceed with the key retrieval.
[0882] Thus, In step S3542, a user may submit a claim for a lost
private key, which may be received by a secure storage service
storing a copy of the user's private key.
[0883] In step S3544, the secure storage system may authenticate
the identity of the claimant, in manners described for step S3524
of FIG. 38B.
[0884] In step S3546, the system may check the account balance of
the account.
[0885] In step S3548, the system may determine whether to proceed
with the requested key retrieval. In embodiments, retrieval may be
halted if an account balance is above a threshold or below a
threshold.
[0886] In step S3550, the system may correlate the received claim
to one or more locations where private key segments may be
stored.
[0887] In step S3552, a message, which may constitute instructions,
may be transmitted to one or more storage facilities to retrieve
the private key segments.
[0888] In step S3554, the private key segments may be verified.
[0889] In step S3556, the private key segments may be transmitted
to a device and/or account corresponding to the user of the
account. In embodiments, decryption, reassembly, and or deciphering
of private keys and/or key segments may occur before or after
returning the keys and/or key segments to a user and may be
performed by the system or by a user, who may use software provided
by the system.
[0890] In step S3558, the system may receive confirmation that the
user received the private key segments.
[0891] In exemplary embodiments, a user of a secure storage service
or system may be required to provide proof of control of an account
before a lost key for that account may be recovered and provided to
the user. Exemplary systems and methods for implementing such proof
of control are described in further detail below.
Increasing the Total Supply of Digital Asset Tokens
[0892] FIGS. 39A-39B illustrates a process for increasing a total
supply of digital asset tokens in accordance with exemplary
embodiments of the present invention. The process of FIGS. 39A
through 39B may begin at a step S3902. At step S3902, a first
designated key pair (e.g. on-line keyset 1 1362) may be provided.
In embodiments, the first designated key pair may include, at
least, a first designated public key and a corresponding first
designated private key. The first designated public key, in
embodiments, may be used to provide a first designated public
address, which may be associated with an underlying digital asset.
The underlying digital asset (e.g. Neo, ether, to name a few) may
be maintained on a distributed public transaction ledger maintained
in the form of a blockchain. In embodiments, a first computer
system may store the first designated private key, similarly to
on-line keyset 1 1362. The first computer system may have access
to, or be connected with, the distributed public transaction ledger
through a network, such as the internet (e.g. network 15). In
embodiments, the first designated private key may be mathematically
related to the first designated public key. In embodiments, the
first designated public address is the first designated public key.
In embodiments, the first designated public address is derived from
the first designated public key.
[0893] In embodiments, the first designated key pair may include a
plurality of key pairs (e.g. on-line keyset N 1362N). For example,
the first designated key pair may further include a first
additional designated public key and a corresponding first
additional designated private key. In embodiments, each key pair of
the aforementioned plurality of key pairs of the first designated
key pair may each correspond to a designated public address. For
example, a first key pair of the plurality of key pairs may
correspond to a first designated public address associated with the
underlying digital asset. A second key pair of the plurality of key
pairs may correspond to a second designated public address
associated with the underlying digital asset. In embodiments, each
key pair of the aforementioned plurality of key pairs may
correspond to the same designated public address. For example, the
first and second key pairs mentioned in the examples above may be
associated with the same designated public address.
[0894] In embodiments, the first designated public address may be
derived by using and/or applying a cryptographic hash function of
the first designated public key. In embodiments, the first
designated public address is a result of the cryptographic hash
function, or, in embodiments, at least a part of the result of the
cryptographic hash function. A cryptographic hash function may be a
hash function that is a mathematical algorithm which maps data of
arbitrary size to a bit string of a fixed size (e.g. a hash). In
embodiments, the cryptographic hash function may be designed to be
a one-way function (e.g. a function that is infeasible to invert).
The cryptographic hash function, may include one or more of the
following prosperities: (1) deterministic such that the same
message produces results in the same hash; (2) high speed, such
that the hash value for a message is computed in a manner that does
not slow the process down; (3) infeasible to generate a message
from the hash, such that generating a message from the hash value
would require attempting all possibilities (e.g. a brute force
approach); and (4) unique, such that messages to not have the same
hash value and/or small changes to a message alter the hash value
such that the values do not correlate, to name a few.
[0895] The process of FIGS. 39A through 39B may continue at a step
S3904. At step S3904, a second designated key pair (e.g. off-line
keyset 1 1803) is provided. The second designated key pair, similar
to the first designated key pair, may include a second designated
public key and a corresponding second designated private key. The
second designated public key may be mathematically related to the
corresponding second designated private key. In embodiments, the
second designated key pair may correspond to the same public
address as the first designated key pair (e.g. the first designated
public address associated with the underlying asset). In
embodiments, the second designated key pair may correspond to a
different public address than the first designated key pair. For
example, the first designated key pair may correspond to the first
designated public address and the second designated key pair may
correspond to a second designated public address. In embodiments,
where the second designated key pair corresponds to a second
designated public address, the second designated public address may
be the second designated public key.
[0896] In embodiments, the second designated key pair may be stored
on a second computer system. The second computer system may be
physically and/or operationally separated from the first computer
system. Additionally, the second computer system may be physically
and/or operationally separated (e.g. not connected to) from the
distributed public transaction ledger and/or the internet (e.g.
network 15). This separation, as described above in connection with
FIG. 18A, may be for security purposes, adding an additional layer
of security by ensuring that unwanted access is not granted via
network 15.
[0897] In embodiments, the second computer system may be a hardware
storage module. The hardware storage module may be located in a
vault (e.g. Vault 70-A1) Location A, Location B, Location C . . .
Location N described above in connection with FIGS. 31A-31D.
Additionally, a more detailed description of storage, and
particularly cold storage, is located above under the "Cold
Storage" heading.
[0898] In embodiments, the hardware storage module, may include one
or more types of storage mediums such as any volatile or
non-volatile memory, or any removable or non-removable memory
implemented in any suitable manner to store the second designated
key pair. For example, the second designated key pair may be stored
using computer-readable instructions, data structures, and/or
program systems. Various types of storage/memory may include, but
are not limited to, hard drives, solid state drives, flash memory,
permanent memory (e.g., ROM), electronically erasable programmable
read-only memory ("EEPROM"), CD-ROM, digital versatile disk ("DVD")
or other optical storage medium, magnetic cassettes, magnetic tape,
magnetic disk storage or other magnetic storage devices, RAID
storage systems, or any other storage type, or any combination
thereof, to name a few.
[0899] In embodiments, the second designated key pair may include a
plurality of key pairs (e.g. off-line keyset N 1803N). For example,
the second designated key pair may further include a first
additional designated public key and a corresponding first
additional designated private key. In embodiments, each key pair of
the aforementioned plurality of key pairs of the second designated
key pair may each correspond to a designated public address. For
example, a first key pair of the plurality of key pairs may
correspond to a first designated public address associated with the
underlying digital asset. A second key pair of the plurality of key
pairs may correspond to a second designated public address
associated with the underlying digital asset. In embodiments, each
key pair of the aforementioned plurality of key pairs may
correspond to the same designated public address. For example, the
first and second key pairs mentioned in the examples above may be
associated with the same designated public address.
[0900] In embodiments, the second designated public address may be
derived by using and/or applying a cryptographic hash function of
the second designated public key. In embodiments, the second
designated public address is a result of the cryptographic hash
function, or, in embodiments, at least a part of the result of the
cryptographic hash function. The cryptographic hash function
applied may be similar and/or the same cryptographic hash function
applied to the first designated key pair. In embodiments, the
cryptographic hash function applied to the second designated key
pair may be different than the cryptographic hash function applied
to the first key pair. A different cryptographic hash function may
be used, in embodiments, as an additional security measure.
[0901] In embodiments, the process of FIG. 39A may continue with
step S3906 where first smart contract instructions (e.g. PROXY
Contract Instructions 1310A-1) associated with a first smart
contract (e.g. PROXY Smart Contract 1310) are provided. The first
smart contract may have a corresponding first contract address
(e.g. Contract Address 1 of Proxy Smart Contract 1310) associated
with the blockchain of the underlying digital asset. In
embodiments, the first smart contract instructions may be saved as
part of the blockchain of the underlying digital asset and/or
include one or more of the following instructions: (1) first
delegation instructions and/or (2) first authorization
instructions, to name a few. The first delegation instructions may
delegate one or more first functions associated with the digital
asset token to one or more delegated contract addresses associated
with the blockchain of the underlying digital asset. The one or
more delegated contract addresses, in embodiments, may be different
than the first contract address. For example the one or more
delegated contract addresses may include a second contract address,
which may be different than the first contract address. The first
delegation instructions may similar to the delegation instructions
described above in connection with PROXY Delegation Instructions
Module 1829.
[0902] The first authorization instructions, in embodiments, may be
associated with the second designated key pair. In embodiments,
first authorization instructions may be similar to the
authorization instructions described above in connection with PROXY
Authorization Instructions Module 1831.
[0903] In embodiments, the first smart contract may be PROXY smart
contract 1310 described above in connection with FIGS. 18A and 18B,
the description of which applying herein.
[0904] The process or FIG. 39A may continue with step S3908 where
second smart contract instructions (e.g. PRINT LIMITER Contract
Instructions 1360A-1) associated with a second smart contract (e.g.
PRINT LIMITER Smart Contract 1360) is provided. The second smart
contract may be associated with a second contract address (e.g.
Contract Address 3 described above in connection with the PRINT
LIMITER Smart Contract 1360) associated with the blockchain of the
underlying digital asset. The second smart contract instructions
may be saved as part of the blockchain for the underlying digital
asset and/or include one or more of the following instructions: (1)
print limiter token creation instructions, (2) second authorization
instructions, and/or (3) third authorization instructions, to name
a few.
[0905] The print limiter token creation instructions, in
embodiments, may indicate one or more conditions under which
digital asset tokens of the underlying digital asset are created.
In embodiments, the print limiter token creation instructions may
be similar to the PRINT LIMITER token creation instructions
described above in connection with the PRINT LIMITER Token Creation
Instructions Module 1833.
[0906] The second authorization instructions, in embodiments, may
include instructions to create tokens of the digital asset token.
In embodiments, the first designated key pair is designated to
authorize the second authorization instructions. In embodiments,
the second designated key pair is designated to authorize the
second authorization instructions. The second authorization
instructions, in embodiments, may include instructions limiting the
creation of digital asset tokens. The limitation placed on token
creation may prevent the creation of tokens above a first
threshold. For example, the second authorization instructions may
limit the creation of tokens to 100,000 tokens. In embodiments, the
first threshold may be relative to a first period of time. For
example, the second authorization instructions may limit the
creation of tokens to 500,000 tokens per day. In embodiments, the
second authorization instructions may be similar to the first
authorization instructions described above in connection with PRINT
LIMITER First Authorization Instructions Module 1839.
[0907] The third authorization instructions, in embodiments, may
also include instructions with respect to token creation. In
embodiments, the third authorization instructions may designate a
first designated custodian address (e.g. a custodian address
associated with CUSTODIAN 2 Smart Contract 1350) with respect to
token creation of the digital asset token. In embodiments, the
third authorization instructions may be similar to the second
authorization instructions described above in connection with PRINT
LIMITER Second Authorization Instructions Module 1841.
[0908] In embodiments, the second smart contract instructions may
also include token balance modification instructions (e.g.
instructions of the Token Balance Modification Instructions Module
1847). The token balance modification instructions may be related
to modifying the total balance of tokens of the digital asset token
assigned to a third delegated contract address. In embodiments, the
third delegated contract address may be of the one or more
delegated contracted addresses. In embodiments, the token balance
modification instructions may be similar to the optional token
balance modification instructions described above in connection
with Token Balance Modification Instructions Module 1847.
[0909] In embodiments, the second smart contract may further
include additional authorization instructions. The additional
authorization instructions may be similar to the optional PRINT
LIMITER THIRD Authorization instructions described above in
connection with PRINT LIMITER Third authorization Instructions
Module 1835.
[0910] In embodiments, the second smart contract may be PRINT
LIMITER Smart Contract 1360 described above in connection with
FIGS. 18A and 18C, the description of which applying herein.
[0911] In embodiments, the process of FIG. 39A may continue with
step S3910 where third smart contract instructions (e.g. CUSTODIAN
2 Contract Instructions 1350A-1) associated with a first designated
custodian contract (e.g. CUSTODIAN 2 Smart Contract 1350). In
embodiments, the first designated custodian contract is associated
with a third contract address (e.g. Contract Address 6 of CUSTODIAN
2 Smart Contract 1350) associated with the blockchain of the
underlying digital asset. In embodiments, the third contract
address is the first designated contract address designated by the
third authorization instructions of the second smart contract. In
embodiments, the third smart contract instructions are saved as
part of the blockchain of the underlying digital asset and/or
include one or more of the following instructions: (1) fourth
authorization instructions (e.g. authorization instructions
described in connection with CUSTODIAN 2 First Authorization
Instructions Module 1849), and/or (2) sixth authorization
instructions (e.g. authorization instructions described in
connection with CUSTODIAN 2 Second Authorization Instructions
Module 1851), to name a few.
[0912] The fourth authorization instructions, in embodiments, may
authorize the issuance of instructions to the second smart
contract. The issued instructions that are authorized by the fourth
authorization instructions may regard token creation. In
embodiments, the fourth authorization instructions designate the
second designated key pair to authorize the fourth authorization
instructions. In embodiments, the fourth authorization instructions
designate the first key pair to authorize the fourth authorization
instructions. In embodiments, the fourth authorization instructions
include instructions to permit the creation of digital asset tokens
above a first threshold defined by the second authorization
instructions. In embodiments, the fourth authorization instructions
may be similar to the authorization instructions described in
connection with CUSTODIAN 2 First Authorization Instructions Module
1849.
[0913] The sixth authorization instructions, in embodiments, may
designate a seventh contract address as one of the one or more
delegated contract addresses. In embodiments, the seventh contract
address is not the second contract address. In embodiments, the
second designated key pair is designated to authorize the sixth
authorization instructions. In embodiments, the first designated
key pair is designated to authorize the sixth authorization
instructions. In embodiments, the sixth authorization instructions
may be similar to the authorization instructions described in
connection with CUSTODIAN 2 Second Authorization Instructions
Module 1851.
[0914] In embodiments, the third smart contract may be CUSTODIAN 2
Smart Contract 1350 described above in connection with FIGS. 18A
and 18D, the description of which applying herein.
[0915] In embodiments, the process of FIG. 39A may continue with
step S3912 where fourth smart contract instructions (e.g. IMPL
Smart Contract Instructions 1320A-1) associated with a fourth smart
contract (e.g. IMPL Smart Contract 1320). In embodiments, the
fourth smart contract is associated with a fourth contract address
(e.g. Contract Address 2 of IMPL Smart Contract 1320), to name a
few. The fourth contract address, in embodiments, may be one of the
one or more delegated contract address. Additionally, the fourth
contract address, in embodiments, may be different from one or more
of: the first contract address, the second contract address, and/or
the third contract address. The fourth smart contract instructions
may be saved as part of the blockchain and/or include one or more
of the following instructions: (1) token creation instructions
(e.g. instructions of IMPL Token Creation Instructions Module
1865), (2) second delegation instructions (e.g. instructions of
IMPL Delegation Instructions Module 1837), (3) token transfer
instructions (e.g. instructions of IMPL Token Transfer Instructions
Module 1861), and/or (4) token destruction instructions.
[0916] The token creation instructions may, in embodiments, be
instructions to create tokens of the digital asset tokens. In
embodiments, the token creation instructions may create tokens in
accordance with the conditions set forth by the print limiter token
creation instructions of the second smart contract. The token
creation instructions may be similar to instructions described in
connection with the IMPL Token Creation Instructions Module
1865.
[0917] The second delegation instructions, in embodiments, may
delegate data storage operations to at least a fifth contract
address. In embodiments, the fifth contract address may be
associated with Contract Address 4 of STORE Smart Contract 1330.
For example, the second delegation instructions may cause STORE
Smart Contract 1330 to execute storage instructions of Storage
Instructions Module 1853. The second delegation instructions may be
similar to instructions described in connection with IMPL
Delegation Instructions Module 1861.
[0918] In embodiments, the token transfer instructions may be
related to transferring issued tokens of the digital asset token.
The transfer of tokens may be from a first designated contract
address to a second designated contract address. For example,
issued tokens may be transferred from a contract address associated
with a digital asset token issuer system to a user public address
associated with a user attempting to purchase tokens of the
underlying digital asset. The token transfer instructions may be
similar to instructions described in connection with IMPL Token
Transfer Instructions Module 1859.
[0919] In embodiments, the token destruction instructions may be
related to destroying and/or burning one or more issued tokens of
the digital asset token. For example, if a user is attempting to
exchange a token for, as an example, fiat, the token being
exchanged may be burned once the token is exchanged for fiat.
[0920] In embodiments, the fourth smart contract may be IMPL Smart
Contract 1320 described above in connection with FIGS. 18A and 18F,
the description of which applying herein.
[0921] In embodiments, the process of FIG. 39A may continue with
the process of FIG. 39B. The process of FIG. 39B may continue with
step S3914 where fifth smart contract instructions (e.g. STORE
Contract Instructions 1330A-1) associated with a fifth smart
contract (e.g. STORE Smart Contract 1330) are provided. The fifth
contract address, in embodiments, may be one of one or more
designated store contract addresses. In embodiments, the fifth
smart contract instructions may be saved as part of the blockchain
of the underlying digital asset and/or include one or more of the
following instructions: (1) data storage instructions (e.g.
instructions of Storage Instructions Module 1853) and/or (2) fifth
authorization instructions (e.g. instructions of STORE
Authorization Instructions Module 1855), to name a few.
[0922] The data storage instructions, in embodiments, may include
instructions to store transaction data related to the digital asset
token. Transaction data, in embodiments, may include transaction
information for one or more of the issued tokens of the digital
asset token. The transaction information, may include at least one
of: (1) respective public address information associated with the
blockchain of the underlying digital asset, and/or (2)
corresponding respective token balance information which may be
associated with the aforementioned respective public address
information. In embodiments, the transaction data may include
transaction information for all of the issued tokens of the digital
asset token. In embodiments, the data storage instructions may be
similar to instructions described in connection with Storage
Instructions Module 1853.
[0923] The fifth authorization instructions may include
authorization instructions to modify the transaction data in
response to a request. In embodiments, the request may be received
from the fourth contract address. The fifth authorization
instructions may be similar to instructions described above in
connection with STORE Authorization Instructions 1855.
[0924] In embodiments, the fifth smart contract may be STORE Smart
Contract 1330 described above in connection with FIGS. 18A and 18E,
the description of which applying herein.
[0925] In embodiments, the process of FIG. 39B may continue with
step S3916 where the total supply of digital asset tokens may be
increased by a digital asset token issuer system. In embodiments,
the total supply of digital asset tokens may be increased from a
first amount to a second amount. A more detailed description of the
process of step S3916 is located in the flow charts of FIGS.
39C-39E.
[0926] Referring to FIG. 39C, the process of increasing the total
supply of digital asset tokens may begin with step S3920 where a
first transaction request may be generated. The first transaction
request may include a first message that may include a first
request to increase the total supply of digital asset tokens to the
second amount of digital asset tokens. In embodiments, the first
transaction request may be sent from a contract address associated
with the digital asset token issuer system to the fourth contract
address. In embodiments, the first transaction request may be
digitally signed by the first designated private key. In
embodiments, the first transaction request may be signed by the
second designated private key. In embodiments, the first
transaction request may include first transaction fee information
for minors associated with the plurality of geographically
distributed computer systems in the peer-to-peer network. The first
transaction fee information may be a predetermined amount of
currency which may be related to the cost of processing the first
transaction request.
[0927] In embodiments, the first request may be to decrease the
total supply of digital asset tokens to a third amount. This
example may follow the same process described in connection with
FIGS. 39C-39E, with the third amount of digital asset tokens being
less than the first amount of digital asset tokens.
[0928] The process may continue with a step S3922. In embodiments,
at step S3922, the first transaction request may be sent by the
digital asset token issuer system, from the first designated public
address to the fourth contract address. In embodiments, the first
transaction request may be sent via the blockchain of the
underlying digital asset. In embodiments, the first transaction
request may be sent via network 15.
[0929] The process may continue with step S3924 where the first
transaction request may be sent from the fourth contract address to
the second contract address via the blockchain for the underlying
digital asset. In embodiments, once the first transaction request
is received by the second contract address, the second smart
contract may execute the first transaction request. The execution
of the first transaction request may, in embodiments, be to return
a first unique lock identifier associated with the first
transaction request. In embodiments, the first transaction request
is executed via the plurality of geographically distributed
computer systems in the peer-to-peer network with reference to the
blockchain for the underlying digital asset.
[0930] In embodiments, the process may continue with step S3926,
where the digital asset token issuer system may obtain the first
unique lock identifier. In embodiments, the first unique lock
identifier may be obtained based on reference to the blockchain for
the underlying digital asset.
[0931] In embodiments, the process may continue with step S3928
where a second transaction request may be generated by the digital
asset token issuer system. In embodiments, the second transaction
request may be generated in response to the first unique lock
identifier being obtained. The second transaction request may, in
embodiments, include a second message which may include a second
request to unlock the total supply of the digital asset tokens. The
second request may be in accordance with the first request.
Moreover, in embodiments, the second request may include the first
unique lock identifier. In embodiments, the second transaction
request may be digitally signed by the first designated private
key. In embodiments, the second transaction request may be
digitally signed by the second designated private key. In
embodiments, the second transaction request may include second
transaction fee information for minors associated with the
plurality of geographically distributed computer systems in the
peer-to-peer network. The second transaction fee information may be
a predetermined amount of currency which may be related to the cost
of processing the second transaction request.
[0932] The process of FIG. 39C may continue with the process of
FIG. 39D. Referring to FIG. 39D, the process may continue with step
S3930 where the second transaction request may be sent from the
first designated public address to the third contract address. In
embodiments, the second transaction request is sent by the digital
asset token issuer system via the blockchain for the underlying
digital asset. In embodiments, in response to receiving the second
transaction request, the third smart contract may execute the
second transaction request. Executing the second transaction
request, in embodiments, may include returning a first unique
request hash associated with the second transaction request. In
embodiments, the second transaction request is executed via the
plurality of geographically distributed computer systems in the
peer-to-peer network with reference to the blockchain associated
with the underlying digital asset.
[0933] The process may continue with step S3932 where, in
embodiments, the first unique request hash may be obtained by the
digital asset token issuer system. In embodiments, the first unique
request hash may be obtained based on reference to the blockchain
for the underlying digital asset.
[0934] At a step S3934, in embodiments, a third transaction request
may be generated. The third transaction request may, in
embodiments, be generated to be digitally signed by at least the
second designated private key. In embodiments, the third
transaction request may include the first unique request hash. The
third transaction request, in embodiments, may be generated in
response to the digital asset token issuer system obtaining the
first unique request hash.
[0935] In embodiments, at a step S3936, the third transaction
request may be transferred to a first portable memory device. In
embodiments, the third transaction request may be transferred to
the first portable memory device by an administrator (e.g. an
administrator of administrator system 1801). In embodiments, the
third transaction request may be transferred from the digital asset
token issuer system to the first portable memory device. In
embodiments, the first portable memory device, may include one or
more types of storage mediums such as any volatile or non-volatile
memory, or any removable or non-removable memory implemented in any
suitable manner to store the third transaction request. For
example, the third transaction request may be stored using
computer-readable instructions, data structures, and/or program
systems. Various types of storage/memory may include, but are not
limited to, hard drives, solid state drives, flash memory,
permanent memory (e.g., ROM), electronically erasable programmable
read-only memory ("EEPROM"), CD-ROM, digital versatile disk ("DVD")
or other optical storage medium, magnetic cassettes, magnetic tape,
magnetic disk storage or other magnetic storage devices, RAID
storage systems, or any other storage type, or any combination
thereof, to name a few.
[0936] In embodiments, the process may continue with step S3938
where the third transaction request may be transferred from the
first portable memory device to the second computer system. In
embodiments, the third transaction request may be transferred to
the second computer system by an administrator (e.g. an
administrator of administrator system 1801).
[0937] In embodiments, the process of FIG. 39D may continue with
FIG. 39E. Referring to FIG. 39E, at a step S3940, the second
computer system digitally may sign the third transaction request
using the second designated private key. By digitally signing the
third transaction request, the second computer system may generate
a third digitally signed transaction request.
[0938] In embodiments, once the third digitally signed transaction
request is generated, the third digitally signed transaction
request may be transferred from the second computer system to a
second portable memory device. The second portable memory device
may, in embodiments, be the first portable memory device (e.g. the
first and second portable memory device are the same portable
memory device). In embodiments, the second portable memory device
may be physically and operatively separate from the first portable
memory device. In embodiments, the second portable memory device,
may include one or more types of storage mediums such as any
volatile or non-volatile memory, or any removable or non-removable
memory implemented in any suitable manner to store the third
transaction request. For example, the third transaction request may
be stored using computer-readable instructions, data structures,
and/or program systems. Various types of storage/memory may
include, but are not limited to, hard drives, solid state drives,
flash memory, permanent memory (e.g., ROM), electronically erasable
programmable read-only memory ("EEPROM"), CD-ROM, digital versatile
disk ("DVD") or other optical storage medium, magnetic cassettes,
magnetic tape, magnetic disk storage or other magnetic storage
devices, RAID storage systems, or any other storage type, or any
combination thereof, to name a few.
[0939] In embodiments, the process may continue with step S3942
where the third digitally signed transaction request may be sent
from the portable memory device to the third contract address using
the digital asset token issuer system, via the blockchain for the
underlying digital asset. In embodiments, the portable memory
device may be the second portable memory device. To send the third
digitally signed transaction request, in embodiments, the third
digitally signed transaction request may be first transferred from
the second portable memory device to the digital asset token issuer
system. Once transferred, in embodiments, the third digitally
signed transaction request may be sent by the digital asset token
issuer system to the third contract address.
[0940] In response to receiving the third digitally signed
transaction request, in embodiments, the third smart contract may
execute the third digitally signed transaction request. In
embodiments, the execution of the third digitally signed
transaction request may result in a request to validate the second
request to unlock the total supply of digital asset tokens based on
the third digitally signed transaction request and/or the first
unique request hash. In embodiments, the execution may also result
in a first call to the second contract address. The first call may
be to increase the total supply of the digital asset tokens from
the first amount to the second amount. In embodiments, the third
smart contract may execute the third digitally signed transaction
request via the plurality of geographically distributed computer
systems in the peer-to-peer network with reference to the
blockchain of the underlying digital asset.
[0941] The first call sent by the third smart contract to the
second contract address of the second smart contract may, in
embodiments, result in the second contract address returning the
first call to the fourth contract address. The fourth contract
address may, in response to receiving the returned first call,
execute a second call to the fifth contract address. The second
call, in embodiments, may be to set the total supply of the digital
asset tokens to the second amount of digital asset tokens. In
embodiments, the fourth smart contract may execute the second call
via the plurality of geographically distributed computer systems in
the peer-to-peer network with reference to the blockchain of the
underlying digital asset.
[0942] The second call sent by the fourth smart contract to the
fifth contract address of the fifth smart contract may, in
embodiments, result in the fifth smart contract executing the
second call to set the total supply of the digital asset tokens to
the second amount of digital asset tokens. In embodiments, the
fifth smart contract may execute the second call via the plurality
of geographically distributed computer systems in the peer-to-peer
network with reference to the blockchain of the underlying digital
asset.
[0943] In embodiments, the steps of the process described in
connection with FIGS. 39C-39E may be rearranged or omitted.
[0944] Referring back to FIG. 39B, the process may continue with
step S3918, where the digital asset token issuer system may confirm
the total supply of digital asset tokens. The total supply, in
embodiments, may be confirmed by the digital asset token issuer
system as set to the second amount of digital asset tokens based on
reference to the blockchain of the underlying digital asset.
[0945] In embodiments, the digital asset token issuer system may
determine that the total supply of digital asset tokens is not the
second amount of digital asset tokens. For example, the digital
asset token issuer system may determine that the total supply of
digital asset tokens is set to a third amount, the third amount
being different than the second amount of digital asset tokens. In
these embodiments, the digital asset token issuer system may
generate and/or send a warning message for an administrator (e.g.
an administrator of administrator system 1801). In embodiments, the
administrator system may be the token issuer system. In
embodiments, the administrator system may not be the token issuer
system. The warning message may include a notification stating that
the amount of tokens is incorrect and/or needs to be fixed.
Additionally, the warning message may include a transaction ledger
(e.g. Network Digital Asset Transaction Ledger 3228). Moreover, the
warning message may include the third amount of digital asset
tokens. Furthermore, the warning message may include the intended
amount of digital asset tokens (e.g. the second amount of digital
asset tokens). In embodiments, if the digital asset token issuer
system determines the total supply of tokens is incorrect, the
digital asset token issuer system may repeat one or more of the
steps of the processes described above in connection with FIGS.
39A-39E in order to set the amount of digital asset tokens from the
third amount to the second amount.
[0946] In embodiments, the steps of the process described in
connection with FIGS. 39A-39B may be rearranged or omitted.
[0947] In embodiments, a process for increasing a total supply of
digital asset tokens including may begin with providing a first
designated key pair. The first designated key pair, In embodiments,
may include a first designated public key and a corresponding first
designated private key. The first designated private key may also
correspond to a first designated public address associated with an
underlying digital asset. In embodiments, the underlying digital
asset is maintained on a distributed public transaction ledger
maintained in the form of a blockchain by a plurality of
geographically distributed computer systems in a peer-to-peer
network in the form of a blockchain network. In embodiments, the
first designated private key is stored on a first computer system
which is connected to the distributed public transaction ledger
through the Internet (e.g. network 15).
[0948] In embodiments, the process may continue with providing a
second designated key pair. In embodiments, the second designated
key pair includes a second designated public key and a
corresponding second designated private key. In embodiments, the
second designated public key also corresponds to a second
designated public address associated with the underlying digital
asset. In embodiments, the second designated private key is stored
on a second computer system which is physically separated from the
first computer system and is not operatively and/or physically
connected to the distributed public transaction ledger or the
Internet.
[0949] In embodiments, the process may continue with providing
first smart contract instructions associated with a first smart
contract associated with a digital asset token associated with a
first contract address associated with the blockchain associated
with the underlying digital asset. In embodiments, the first smart
contract instructions are saved as part of the blockchain for the
underlying digital assets. In embodiments, the first smart contract
instructions include first delegation instructions to delegate one
or more first functions associated with the digital asset token to
one or more delegated contract addresses associated with the
blockchain associated with the underlying digital asset. The one or
more delegated contract addresses, in embodiments, is different
from the first contract address. In embodiments, a second contract
address is designated as one of the one or more delegated contract
addresses. In embodiments, the first smart contract instructions
include first authorization instructions for the second designated
key pair.
[0950] The process may continue, in embodiments, with providing
second smart contract instructions associated with a second smart
contract associated with the digital asset token associated with
the second smart contract address associated with the blockchain
associated with the underlying digital asset. In embodiments, the
second smart contract instructions are saved as part of the
blockchain for the underlying digital asset. In embodiments, the
second smart contract instructions may include: (1) print limiter
token creation instructions indicating conditions under which
tokens of the digital asset token are created; (2) second
authorization instructions to create tokens of the digital asset
token, wherein the first designated key pair is designated to
authorize said second authorization instructions to create tokens
of the digital asset token; and (3) third authorization
instructions with respect to token creation of the digital asset
token; wherein the third authorization instructions designate a
first designated custodian address with respect to token creation
of the digital asset token, to name a few.
[0951] In embodiments, the process may continue with providing
third smart contract instructions associated with a first
designated custodian smart contract associated with the digital
asset token associated with a third contract address associated
with the blockchain associated with the underlying digital asset.
In embodiments, the third contract address is the first designated
custodian contract address. In embodiments, the third smart
contract instructions are saved as part of the blockchain
associated with the underlying digital asset. In embodiments, the
third smart contract instructions include fourth authorization
instructions to authorize issuance of instructions to the second
smart contract regarding token creation. In embodiments, the fourth
authorization instructions designate the second designated key pair
to authorize the fourth authorization instructions.
[0952] In embodiments, the process may continue with providing
fourth smart contract instructions associated with a fourth smart
contract associated with the digital asset token associated with a
fourth contract address associated with the blockchain associated
with the underlying digital asset. In embodiments, the fourth
contract address is one of the one or more delegated contract
addresses and not: (i) the first contract address, (ii) the second
contract address, and/or (iii) the third contract address. In
embodiments, the fourth smart contract instructions are saved as
part of the blockchain associated with the underlying digital
assets. In embodiments, the fourth smart contract instructions
include: (1) token creation instructions to create tokens of the
digital asset token in accordance with conditions set forth by the
print limiter token creation instructions; and/or (2) second
delegation instructions delegating data storage operations to at
least a fifth contract address, to name a few.
[0953] In embodiments, the process may continue with providing
fifth smart contract instructions associated with a fifth smart
contract associated with the digital asset token associated with
the fifth contract address associated with the blockchain
associated with the underlying digital asset. In embodiments, the
fifth smart contract address is one of the one or more designated
store contract addresses. In embodiments, the fifth smart contract
instructions are saved as part of the blockchain for the underlying
digital assets. In embodiments, the fifth smart contract
instructions include: (1) data storage instructions for transaction
data related to the digital asset token, said transaction data
includes for all issued tokens of the digital asset token: (A)
respective public address information associated with the
blockchain associated with the underlying digital asset; and (B)
corresponding respective token balance information associated with
said respective public address information; and/or (2) fifth
authorization instructions to modify the transaction data in
response to requests from the fourth contract address;
[0954] In embodiments, the process may continue with receiving, by
a digital asset token issuer system, a request to generate and
assign to the first designated public address a first amount of
digital asset tokens;
[0955] In embodiments, the process may continue with generating, by
the digital asset token issuer system, the first amount of digital
asset tokens and assigning said first amount of digital asset
tokens to the first designated public address increasing the total
supply of the digital asset tokens. In embodiments, generating the
first amount of digital asset tokens and assigning said first
amount of digital asset tokens to the first designated public
address may include a sub-process.
[0956] The sub-process may begin with the step of generating, by
the digital asset token issuer system, and sending, using the
digital asset token issuer system via the blockchain network, a
first transaction request: (A) to the fourth contract address; and
(B) including a first message including a first request to generate
the first amount of digital asset tokens and assign said first
amount of digital asset tokens to the first designated public
address. In embodiments; the first transaction request is digitally
signed by the first designated private key. In embodiments, the
fourth smart contract executes, via the plurality of geographically
distributed computer systems in the peer-to-peer network with
reference to the blockchain, the first transaction request to: (i)
validate the first request and the authority of the first
designated private key to call the second smart contract to execute
the first request; and (ii) send a first call to the fourth
contract address to generate and assign to the first designated
public address the first amount of digital asset tokens. In
embodiments, the fourth smart contract executes, via the plurality
of geographically distributed computer systems in the peer-to-peer
network with reference to the blockchain, the first call to
generate a first unique lock identifier, and return to the second
smart contract address, the first unique lock identifier. In
embodiments, in response to the return of the first unique lock
identifier, the second smart contract executes, via the plurality
of geographically distributed computer systems in the peer-to-peer
network with reference to the blockchain, a call to the fourth
smart contract address to confirm the first call with the first
lock identifier. In embodiments, in response, the fourth smart
contract executes, via the plurality of geographically distributed
computer systems in the peer-to-peer network with reference to the
blockchain, the first call to execute a second call to the fifth
contract address to obtain the total supply of digital asset tokens
in circulation. In embodiments, in response, the fifth smart
contract executes, via the plurality of geographically distributed
computer systems in the peer-to-peer network with reference to the
blockchain, the second call and returns, to the fourth contract
address, a second amount of digital asset tokens corresponding to
the total supply of digital asset tokens in circulation. In
embodiments, in response to the return of the second amount, the
fourth smart contract, executes via the plurality of geographically
distributed computer systems in the peer-to-peer network with
reference to the blockchain, a third call request to the fifth
contract address to set a new total supply of digital asset tokens
in circulation to a third amount, which is the total of the first
amount and the second amount. In embodiments, in response to the
third call, the fifth smart contract, executes via the plurality of
geographically distributed computer systems in the peer-to-peer
network with reference to the blockchain, the third call and sets a
new total supply of digital asset tokens in circulation at the
third amount. In embodiments, the fourth smart contract executes,
via the plurality of geographically distributed computer systems in
the peer-to-peer network with reference to the blockchain, a fourth
call to the fifth contract address to add the first amount of
digital asset tokens to a respective balance associated with the
first designated public address. In embodiments, in response, the
fifth smart contract executes, via the plurality of geographically
distributed computer systems in the peer-to-peer network with
reference to the blockchain, the fourth call to set the balance of
digital asset tokens in the first designated public address at a
fourth amount which includes the addition of the first amount to
the previous balance.
[0957] The process for increasing the total supply of digital asset
tokens may continue with confirming, by the digital asset token
issuer system, that the balance of digital asset tokens associated
with the first designated public address is set to include the
first amount of digital asset tokens based on reference to the
blockchain.
[0958] In embodiments, the second computer system is a hardware
storage module.
[0959] In embodiments, the second designated key set includes an
additional designated key set including an additional designated
public address and an additional designated private key.
[0960] In embodiments, the second authorization instructions for
the first designated key set with respect to token creation of the
digital asset token include instruction limiting token creation
above a first threshold over a first period of time.
[0961] In embodiments, the fourth authorization instructions for
the second designated key set to authorize the issuance of
instructions to the second smart contract instructions with respect
to token creation include instructions to allow for creation of
digital asset tokens above the first threshold during the first
period of time.
[0962] In embodiments, the third smart contract instructions
further include: (2) sixth authorization instructions to designate
a seventh contract address as one of the one or more delegated
contract addresses. In embodiments, the seventh contract address is
not the second contract address. In embodiments, the second
designated key set is designated to authorize the sixth
authorization instructions. In embodiments, the fourth smart
contract instructions further include: (3) token transfer
instructions related to transferring tokens of the digital asset
token from a first designated contract address to a second
designated contract address. In embodiments, the fourth smart
contract instructions further include: (3) token destruction
instructions related to destroying one or more digital asset token.
In embodiments, the fourth smart contract instructions further
include: (3) token balance modification instructions related to
modifying a total number of tokens of the digital asset token
assigned to a third designated public address. In embodiments, the
fourth smart contract instructions further include: (3) token
transfer instructions related to transferring tokens of the digital
asset token from a first designated contract address to a second
designated contract address; and (4) token destruction instructions
related to destroying one or more tokens of the digital asset
token.
[0963] In embodiments, the process further includes receiving,
prior to generating the first amount of digital asset tokens, a
validating request. In embodiments, the process further includes
determining the first designated key set has authority to process
the request to generate the first amount of digital tokens.
[0964] In embodiments, the first transaction request includes first
transaction fee information for miners in the plurality of
geographically distributed computer systems in the peer-to-peer
network to process the first transaction request.
[0965] In embodiments, the fifth contract returns the balance of
digital asset tokens to the fourth smart contract address. In
embodiments, the fifth contract returns the balance of digital
asset tokens to the second smart contract address.
[0966] In embodiments, the process further for increasing the total
supply of digital asset tokens continues with receiving, by the
plurality of geographically distributed computer systems in the
peer-to-peer network, from a first user device associated with the
first designated public address, via the underlying blockchain, a
second transaction request: (A) from the first designated public
address; (B) to the first contract address; and (C) including a
second message including a second request to transfer a fifth
amount of digital assets from the first designated public address
to a third designated public address. In embodiments, the first
transaction request is digitally signed by the first designated
private key, which is mathematically related to the first
designated public address. In embodiments, the first user device
had access to the first designated private key prior to sending the
second transaction request. In embodiments, the first smart
contract executes, via the plurality of geographically distributed
computer systems in the peer-to-peer network, the second
transaction request to execute, via the plurality of geographically
distributed computer systems in the peer-to-peer network, a sixth
call request to the fourth contract address to transfer a fifth
amount of digital assets from the first designated public address
to the third designated public address;. In embodiments, in
response to the sixth call request, the fourth smart contract,
executes via the plurality of geographically distributed computer
systems in the peer-to-peer network, sixth authorization
instructions to verify the sixth call came from an authorized
contract address, and upon verification, to execute a seventh call
request to the fifth contract address to obtain a sixth amount of
digital asset tokens which reflect a current balance of digital
asset tokens associated with the first designated public address.
In embodiments, in response to the seventh call request, the fifth
smart contract, executes via the plurality of geographically
distributed computer systems in the peer-to-peer network, the
seventh call request to return the sixth amount of digital asset
tokens In embodiments, in response to the return of the sixth
amount of digital asset, the fourth smart contract executes, via
the plurality of geographically distributed computer systems in the
peer-to-peer network: (1) a balance verification instruction to
confirm that the fifth amount of digital asset tokens is less than
or equal to the sixth amount of digital asset tokens, and (2) in
the case where the fifth amount of digital asset tokens is less
than or equal to the sixth amount of digital asset tokens, execute,
via the plurality of geographically distributed computer systems in
the peer-to-peer network, a seventh call request to the fifth
contract address to set a new balance for the digital asset tokens
in the first designated public address to a seventh amount which
equals the sixth amount less the fifth amount. In embodiments, in
response to the seventh call, the fifth smart contract executes,
via the plurality of geographically distributed computer systems in
the peer-to-peer network, the seventh call to set and store the new
balance for the first designated public address as the seventh
amount and returns a new balance for the first designated public
address as the seventh amount. In embodiments, in response to the
return of the new balance, the fourth smart contract executes, via
the plurality of geographically distributed computer systems in the
peer-to-peer network, an eighth call to add the second amount of
digital asset tokens to the balance associated with the third
designated public address. In embodiments, in response to the
eighth call request, the fifth smart contract executes, via the
blockchain network, the eighth call request to set the balance of
digital asset tokens associated with the third designated public
address at a seventh amount which includes the addition of the
second amount to a previous balance associated with the third
designated public address; and wherein the first user device
confirms that the balance of digital asset tokens associated with
the first designated public address is the sixth amount of digital
asset tokens based on reference to the blockchain.
[0967] In embodiments, the second transaction request includes
second transaction fee information for miners in the plurality of
geographically distributed computer systems in the peer-to-peer
network to process the second transaction request. In embodiments,
the balance of digital asset tokens associated with the third
designated public address is returned to the fourth contract
address. In embodiments, the balance of digital asset tokens
associated with the third public address is returned to the first
smart contract address. In embodiments, a second user device
confirms that the balance of the digital asset tokens associated
with the third designated public address is the seventh amount of
digital asset tokens based on reference to the blockchain.
[0968] In embodiments, the process of increasing the total supply
of digital asset tokens further includes providing a third
designated key set, including a third designated public address
associated with the underlying digital asset and a corresponding
third designated private key, and wherein the third designated
private key is stored on a third computer system which is connected
to the distributed public transaction ledger through the
Internet.
[0969] In embodiments, the process continues with receiving, by the
plurality of geographically distributed computer systems in the
peer-to-peer network, from the third computer system, via the
blockchain, a second transaction request: (A) from the third
designated public key address; (B) to the fifth contract address;
and (C) including a second message including a request to burn a
fifth amount of digital asset tokens from a balance associated with
the third designated public address. In embodiments, the second
transaction request is digitally signed by the third designated
private key. In embodiments, the fourth smart contract executes,
via the plurality of geographically distributed computer systems in
the peer-to-peer network, the second transaction request to
execute, via the plurality of geographically distributed computer
systems in the peer-to-peer network, a sixth call request to the
fifth contract address to obtain a sixth amount of digital asset
tokens which reflect a current balance of digital asset tokens
associated with the third designated public address. In
embodiments, in response to the sixth call request, the fifth smart
contract, executes via the plurality of geographically distributed
computer systems in the peer-to-peer network, the seventh call
request to return the sixth amount of digital asset tokens;
wherein, in response to the return of the sixth amount of digital
asset, the fourth smart contract executes, via the plurality of
geographically distributed computer systems in the peer-to-peer
network: (1) a balance verification instruction to confirm that the
fifth amount of digital asset tokens is less than or equal to the
sixth amount of digital asset tokens; and (2) in the case where the
fifth amount of digital asset tokens is less than or equal to the
sixth amount of digital asset tokens, execute, via the plurality of
geographically distributed computer systems in the peer-to-peer
network, a seventh call request to the fifth contract address to
set a new balance for the digital asset tokens associated with the
third designated public key address to a seventh amount which
equals the sixth amount less the fifth amount. In embodiments, in
response to the seventh call, the fifth smart contract executes,
via the plurality of geographically distributed computer systems in
the peer-to-peer network, the seventh call to set and store the new
balance for the third designated public key address as the seventh
amount and returns the new balance for the third designated public
key address as the seventh amount. In embodiments, in response to
the return of the new balance, the fourth smart contract executes,
via the blockchain network, an eighth call request to the fifth
contract address to obtain a total supply of digital asset tokens
in circulation. In embodiments, in response to the eighth call
request, the fifth smart contract executes, via the plurality of
geographically distributed computer systems in the peer-to-peer
network, the eighth call request and returns, to the fourth
contract address, an eighth amount of digital asset tokens
corresponding to the total supply of digital asset tokens in
circulation. In embodiments, in response to the return of the
eighth amount, the fourth smart contract, executes via the
plurality of geographically distributed computer systems in the
peer-to-peer network, a ninth call request to the fifth contract
address to set a new total supply of digital asset tokens in
circulation to a ninth amount, which is the eighth amount less the
fifth amount. In embodiments, in response to the ninth call
request, the fifth smart contract, executes via the blockchain
network, the ninth call request and sets a new total supply of
digital asset tokens in circulation at the ninth amount, and
returns to the fourth contract address.
[0970] In embodiments, the third designated key set is the first
designated key set. In embodiments, the third designated key set is
not the second designated key set. In embodiments, the third
designated key set is the second designated key set. In
embodiments, the third designated key set is not the first
designated key set. In embodiments, the third computer system is
the first computer system. In embodiments, the third computer
system is not the first computer system. In embodiments, the
administrator computer system (e.g. Administrator 1801) includes
the first computer system and the third computer system. In
embodiments, the administrator computer system includes the first
computer system and the second computer system.
[0971] In embodiments, the underlying digital asset is a stable
value token. In embodiments, the underlying digital asset is Neo.
In embodiments, the underlying digital asset is Ether. In
embodiments, the underlying digital asset is Bitcoin.
[0972] In embodiments, the first designated private key is
mathematically related to the first designated public key.
[0973] In embodiments, wherein the first designated public address
includes the first designated public key.
[0974] In embodiments, the first designated public address includes
a hash of the first designated public key.
[0975] In embodiments, the first designated public address includes
a partial hash of the first designated public key.
[0976] In embodiments, the second designated private key is
mathematically related to a second designated public key.
[0977] In embodiments, the second designated public address
includes the second designated public key.
[0978] In embodiments, the second designated public address
includes a hash of the second designated public key.
[0979] In embodiments, the second designated public address
includes a partial hash of the second designated public key.
[0980] In embodiments, the second smart contract instructions
include sixth authorization instructions related to modifying a
token supply of the digital asset token.
Holding Collateral in a Smart Contract on an Underlying
Blockchain
[0981] FIG. 24 illustrates a schematic drawing of an exemplary
network for holding collateral in a smart contract on an underlying
blockchain in accordance with exemplary embodiments of the present
invention. The network shown in FIG. 24 may include a security
token administrator system 6801 associated with an issuer of a
security token 6805 (Security Token), a stable value token
administrator system 6809 associated with an issuer of a stable
value token 6807 (SV Coin Token), and a plurality of end user
devices 105a, 105b, . . . 105N, each associated one or more
corresponding end users. In embodiments, more than one end user
device may be associated with the same end user.
[0982] In embodiments, each of systems 6801, 8609 and user devices
105a, 105b . . . 105N may communicated with and/or among each other
directly and/or indirectly, e.g., through a data network 15, such
as the Internet. In embodiments, encryption and/or other security
protocols may be used. In embodiments, data network 15, may be a
wide area network, a local area network, a telephone network,
dedicated access lines, a proprietary network, a satellite network,
a wireless network, a mesh network, or through some other form of
end-user to end-user interconnection, which may transmit data
and/or other information. Any participants in a digital asset
network may be connected directly or indirectly, as through the
data network 15, through wired, wireless, or other connections.
[0983] In embodiments, issuer of the security token may be one or
more entities. In embodiments, the issuer of the stable value token
may be one or more entities. In embodiments, the issuer of the
security token and the issuer of the stable value token may be the
same or different entity. In embodiments, one or more
administrators may operate the security token administrator system
6801 on behalf of the issuer of the stable value token. In
embodiments, the same or different administrators may operate the
stable value token administrator system 6809. In embodiments, the
issuers and/or administrators may be a trust company, a regulated
trust company, a bank, a broker dealer, or some other form of
entity, to name a few.
[0984] In embodiments, the administrator system 6801 may access one
or more databases stored on non-volatile computer readable memory
including contract parameters data base 6801B, key information data
6801C and smart contract information 6801D. As further illustrated
in FIG. 25A, in embodiments, contract parameters database 6801B may
include at least the following smart contract terms or attributes:
(1) inception date data 6902; (2) inception value data 6904; (3)
benchmark data 6906; (4) contract duration data 6908; (5)
collateral requirements data 6910; and (6) notional value data
6912, to name a few. In embodiments, other contract parameters may
be stored in the contract parameters database. Additional
databases, to name a few, are discussed above in connection with
FIGS. 6A, 10, 26, 29, 30E, 57, 60, 61A, 61B, and 65C-1-2. Moreover,
additional databases may include the databases discussed above in
connection with the descriptions of Blockchain Financial
Instruments, Digital Asset Exchanges, and Digital Wallets, to name
a few. In embodiments, inception date data 6902 may refer to data
that indicates dates at which smart contracts actually begin. In
embodiments, inception value data 6904 may refer to data that
indicates a value of smart contracts at a corresponding inception
date. Benchmark data 6906 may refer to data that indicates
benchmark information of which smart contracts are based off. In
embodiments, contract duration data 6908 may refer to durations of
smart contracts. In embodiments, collateral requirements data 6910
may refer to specific collateral requirements for smart contracts.
In embodiments, notional value data 6912 may refer to the total
amount of a security's underlying asset at its spot price in
reference to smart contract values.
[0985] As illustrated in FIG. 24, the administrator system 6801,
stable value administrator 6809, and/or user devices 105a, 105b
and/or 105N may communicate with a blockchain network to access
and/or add blocks to blockchain 6803. The blockchain 6803 may
include one or more tokens, such as Security Token 6805 and SVCoin
Token 6807 as illustrated. Each token will have at least one
corresponding smart contract address (e.g., smart contract address
6805A for Security Token 6805, and smart contract address 6807A for
SVCoin Token 6807, to name a few) by which instructions for each
token may be accessed. In embodiments, the smart contract address
may be associated with a proxy smart contract which may then issue
calls to one or more other smart contracts having their own smart
contract addresses.
[0986] As illustrated in FIG. 25B, a security token smart contract
6805B is provided on the underlying blockchain 6803. Security token
6805 may also include a plurality of instruction modules that
collectively make up the smart contract associated with the
security token. By way of illustration, in embodiments, such
modules may include modules of instructions such as: (1) a create
security tokens module 6918; (2) a transfer tokens module 6920; (3)
a destroy security tokens module 6922; (4) an access data module
6924; (5) an authorize instructions module; (6) a calculate excess
collateral module 6928; (7) a generate collateral information
message module 6930; and (8) a send collateral information message
module, to name a few.
[0987] In embodiments, the create security token module 6918 may
include one or more authorization instructions related to creating
security tokens. Such instructions may specify one or more
authorized key pairs or contract addresses that may be authorized
to create security tokens under specified conditions. In
embodiments, the create security module 6918 may include
instructions on increasing the token supply. In embodiments, the
create security token module 6918 may include instructions on how
to create new tokens within pre-approved token supply limits and
how to assign newly created or "minted" tokens to specific
designated public addresses or contract addresses on the underlying
blockchain.
[0988] In embodiments, the transfer tokens module 6920, in
embodiments, may include authorization instructions related to
transferring security tokens. In embodiments, such transfer
instructions may include rules by which certain transfer are
allowed or blocked and may specify one or more key pair or contract
addresses that may be authorized to perform one or more types of
transfer operations. In embodiments, the transfer tokens module
6920 may include authorization instructions related to transferring
stable value tokens to smart contract address 6805A. In
embodiments, the transfer tokens module 6920 may include
authorization instructions related to transferring stable value
tokens from smart contract address 6805A.
[0989] In embodiments, the destroy security tokens module 6922 may
include authorization instructions related to destroying security
tokens, including, in embodiments, instructions on when, and with
whose authority, security tokens associated with one or more
specified addresses shall be destroyed or "burned", and thus
removed from the security token supply.
[0990] The access data module 6924, in embodiments, may include
authorization instructions related to accessing data supplied by a
first authorized third party database (i.e. administrator system
6801), as discussed in further detail elsewhere.
[0991] The authorize instructions module 6926 may further include
instructions to authorize the transfer of stable value tokens from
the second contract address 6805B.
[0992] The generate collateral information message module 6930, in
embodiments, may include instructions to generate a collateral
confirmation message to the administrator system 6801 confirming
receipt of at least one of a first amount of collateral and a
second amount of collateral when at least one of the first amount
of collateral and the second amount of collateral is received.
[0993] In embodiments, the send collateral information message
module 6932 may include instructions to send the collateral
confirmation message to the administrator system 6801 confirming
receipt of at least one of a first amount of collateral and a
second amount of collateral when at least one of the first amount
of collateral and the second amount of collateral is received.
[0994] As illustrated in FIG. 25C, a stable value token smart
contract 6807B is provided on the underlying blockchain 6803.
Stable value token 6807 may also include a plurality of instruction
modules that collectively make up the smart contract associated
with the stable value token. By way of illustration, in
embodiments, such modules may include modules of instructions such
as: (1) a create stable value token module 6934; (2) a transfer
stable value token module 6936; (3) a destroy stable value token
module 6938; and (4) authorization instruction module.
[0995] In embodiments, the create stable value token module 6934
may include authorization instructions related to creating stable
value tokens.
[0996] The transfer stable value token module 6936, in embodiments,
may include authorization instructions related to transferring
stable value tokens.
[0997] In embodiments, the destroy stable value token module 6938
may include authorization instructions related to destroying stable
value tokens.
[0998] In embodiments, the authorization instruction module 6940
may include authorization instructions related to functions
associated with the stable value tokens. In embodiments,
authorization instructions module 6940 may also include
instructions to authorize request received, the requests, in
embodiments, being transaction requests from administrators, user
public addresses, or other smart contracts.
[0999] While security token 6805 is described as a security token,
in embodiments, the security token may reflect other types of
tokens, such as tokens associated with a security, a bond, a
financial instrument, a contract, and stock, to name a few.
Similarly, while the SVCoin token 6807 is describe a stable value
token, in embodiments, the SVCoin token 6807, may reflect other
kinds of token which may not necessarily reflect a stable value,
e.g., Gas tokens, and/or some other kind of token which the parties
to the transaction reflect as an appropriate collateral.
[1000] Referring to FIG. 28, an exemplary process for generating a
smart contract in accordance with an embodiment of the present
application is provided. In embodiments, the process shown in FIG.
28 may begin at a step S7302. In step S7302, an administrator
system (i.e. administrator system 6801) may receive a contract
request. In embodiments, the contract request may be received from
a first user, and includes user identification information and a
request to generate a smart contract. In embodiments, the first
user may be an individual, associated with a first user device. In
embodiments, the user identification information may be associated
with the first user. In embodiments, the user identification
information may be associated with a first user device. In
embodiments, the first user may not be an individual, but may be an
organization or entity such as a financial institution, exchange or
brokerage house, to name a few. In embodiments, the first user
device may be associated with a financial institution, exchange or
brokerage house, to name a few. In embodiments, the first user
device may be User device 105a. The contract request, in
embodiments, may also include a smart contract generation request.
The smart contract generation request, in embodiments, is a request
from a user device, associated with a first user, to an
administrator system to generate a smart contract.
[1001] In embodiments, a contract request may be from more than one
user. In embodiments, a first user and second user may agree in
advance, as to contract parameters, and one or the other may send a
contract request that includes first user identification
information associated with a first user device that is associated
with a first user as well as second used identification information
associated with a second user device that is associated with a
second user. The first user device, in embodiments, may be User
device 105a. In embodiments, the second user device may be User
device 105b. The contract request, in embodiments, may include a
smart contract generation request. The smart contract generation
request, in embodiments, is a request from a user device to an
administrator system to generate a smart contract.
[1002] In embodiments, the contract request may be for a contract
where the parameters are already agreed upon by more than two users
(i.e. User device 105a, User device 105b, . . . User device 105n).
For example, where the contract parameters are already agreed upon
by more than two users, the contract request may include user
information for each of the users of which have already agreed upon
the parameters of the requested contract. The contract request, in
embodiments, may also include a smart contract generation
request.
[1003] Once a contract request is received by the administrator
system, at step S7304, the administrator system may generate
graphical user interface (GUI) information including at least one
prompt for the first user to provide contract parameters related to
the smart contract to be generated. In embodiments, the
administrator system may also generate GUI information that prompts
a user to input information corresponding to the contract
parameters similar to or the same as the published contracts
parameters described in connection with FIGS. 71A-71B (i.e.
inception date 7104, inception value 7106, benchmark data 7108,
contract duration data 7110, collateral requirement 7112, notional
value 7114, early termination rules 7130, and second benchmark data
7132, to name a few) and the contract parameters of contract
parameters data base 6801B described in connection with FIG. 25A,
the descriptions of which applying herein. In embodiments, the
administrator system may generate graphical user interface (GUI)
information including at least one prompt for the second user to
provide contract parameters related to the smart contract to be
generated.
[1004] Once the GUI information is generated, at step S7306, the
administrator system may send the GUI information to the first user
device. In embodiments, once received by the first user device, the
first user device may use the GUI information to display a GUI. In
embodiments, such as embodiments where the contract parameters are
already agreed upon by more than one user, the administrator system
may send the GUI information to the first user device and the
second user device. In embodiments, once received, the first and
second user devices may each use the GUI information to display a
GUI. In embodiments, such as embodiments where the parameters are
already agreed upon by more than two users, the administrator
system may send the GUI information to more than two user devices.
In embodiments, once received, the more than two user devices may
each use the GUI information to display a GUI.
[1005] In embodiments, once the GUI information is received by the
first user device, the first user device may receive one or more
inputs which may include contract information including the
contract parameters. For example, the user device may receive
inputs that indicate an inception date 7104, inception value 7106,
benchmark data 7108, contract duration data 7110, collateral
requirement 7112, notional value 7114, early termination rules
7130, and second benchmark data 7132, to name a few. In
embodiments, where the GUI information is sent to more than one
device, for example, where the GUI information is sent to a first
user device and a second user device, at least one of the user
devices may receive inputs which may include contract information
including the contract parameters. The contract information
including the contract parameters may, in embodiments, be sent from
the first and or second user devices to the administrator
system.
[1006] At a step S7308, the administrator system may receive, from
the first user device, in response to the at least one prompt
included in the graphical user interface information, contract
information including the contract parameters of the contract to be
generated. In embodiments, such as embodiments where the contract
parameters are already agreed upon by more than one user, the
administrator system may receive contract information including the
contract parameters of the contract to be generated from at least
one of the first user device and the second user device. In
embodiments, such as embodiments where the parameters are already
agreed upon by more than two users, the administrator system may
receive contract information including the contract parameters of
the contract to be generated from at least one of the user devices
associated with the users that have already agreed upon the
contract parameters.
[1007] Once the contract information is received by the
administrator system, at a step S7310, the administrator system may
store the contract information including the contract parameters in
memory operably connected to the administrator system. In
embodiments, the contract information may be stored in smart
contract information database 6801D.
[1008] In embodiments, the contract parameters provided in the
process described in connection with FIG. 28 may be used in
arranging for multiple transactions based on the contract
parameters. In embodiments, the contract parameters that are
provided by the first user device, for example, may published to a
plurality of user devices, in the same manner as is described below
with respect to step S7002. In this case, users may indicate their
desire to participate in the contract consistent with step S7004
discussed below.
[1009] The steps of the process described in connection with FIG.
28 may be rearranged or omitted.
[1010] In embodiments, the process of FIG. 28 may continue with the
process in FIG. 26A. In alternative embodiments, FIG. 26A may be
its own process, beginning with step S7002. Referring to FIG. 26A,
In step S7002, an administrator system 6801 may publish (via, e.g.
a public or private website or mobile application) a contract
having contract parameters. Contract parameters, as described in
step S7002 may be retrieved from contract parameters database
6801B. In embodiments, as shown in FIG. 25A, contract parameters
database 6801B as discussed before. The published contract, in
embodiments, may have a graphical user interface (GUI), including
such information as shown in connection with FIG. 27A. The
published contract may show some or all of the data described
earlier in connection with FIG. 25A. For example, as shown in FIG.
27A, the published contract 7102 may have (1) an inception date
7104 of Jul. 19, 2018; (2) an inception value 7106 of $10,000; (3)
benchmark data 7108 from the S&P 500; (4) a contract duration
7110 of 5 days; (5) a collateral requirement 7112 of 100 Stable
Value Coins; and (6) a notional value 7114 of $10,000. Other values
and parameters may be included consistent with embodiments of the
present invention. In embodiments, these other values and
parameters may include information that may be used to determine
the contract parameters discussed above, and/or other parameters
including: (1) asset identification information; (2) a current
(spot) price; (3) a type of derivative; (4) a side (buy/sell); (5)
a call/put designation, (6) an expiration date or term, (7) a
strike price; (8) pricing model information, and (10) volatility
information, to name a few. In embodiments, user input of certain
information may prompt requests for additional information. In one
example, input of an identification of a particular type of
derivative may require user identification of other information,
such as upper or lower price limit, to name a few.
[1011] In embodiments, the type of derivative may be any one of:
vanilla, fx hedge, flexi forward, knock out, knock in, double
knockout, double knock in, no touch, one touch, double no touch,
double one touch, digital, digital knockout, digital knockin,
digital double knockout, digital double knockin, compound,
sequential--kiko & kiki, koki--no sequential, digital
sequential, average (Asian), fader, digital accrual, accrual,
accumulator, accumulator KO, accumulator KI, cas, dcd vanilla, dcd
knockout, dcd knockin, average forward, euro-american KO, target
redemption forward, dual-strike tarf, kockin tarf, pivot tarf,
variance swap, volatility swap and forward volatility agreement, to
name a few.
[1012] In embodiments, the pricing model may be any one of:
black-scholes, vanna-volga, heston, local vol, stoch-local vol,
stochastic, to name a few.
[1013] In embodiments, the smart contract parameters database may
further include: (7) early termination rule data 6914; and (8)
second benchmark data 6916, to name a few. In embodiments, early
termination rule data 6914 may include rules that charge a fee
associated with a user terminating the smart contract before the
contract duration is completed. Second benchmark data 6916 in some
embodiments may be different than benchmark data 6906. The
published contract, in embodiments, may include a GUI with such
information as shown in connection with FIG. 27B. In embodiments,
the published contract may show some or all of the data described
earlier in connection with FIG. 25A. For example, as shown in FIG.
27B, the published contract 7116 may have (1) an inception date
7118 of Jul. 20, 2018; (2) an inception value 7120 of $1,000; (3)
benchmark data 7122 from the S&P 500; (4) a contract duration
7124 of 2 days; (5) a collateral requirement 7126 of 10 Stable
Value Coins; (6) a notional value 7128 of $1,000; (7) no early
termination rules 7130; and (8) second benchmark data 7132 from
Winkdex.RTM.. While there are no early termination rules shown in
the published contract of FIG. 27B, early termination rules may
include, for example, a fee for terminating the contract early.
Other values and parameters may be included consistent with
embodiments of the present invention.
[1014] Referring to FIG. 26A, In step S7004, the administrator
system 6801 may receive a plurality of indications of interest
("IOIs") or bids from users. Referring to FIGS. 27C-27F, the IOIs
may include at least a first indication of interest (e.g. first
indication of interest 7134 described in connection with FIG. 27C
or first indication of interest 7140 described in connection with
FIG. 27D) and a second indication of interest (e.g. second
indication of interest 7150 described in connection with FIG. 27E
or second indication of interest 7156 described in connection with
FIG. 27F). In embodiments, the first indication of interest may be
a first user response sent from a first user device 105a to
administrator system 6801. In embodiments, the first user device
105a may be associated with a first user (e.g. Alice). In
embodiments, as illustrated in FIGS. 71C and 71D, the first
indication of interest7134, 7140 may include at least first user
identification information 7136, 7142 associated with the first
user (e.g., a name, user number, email address, to name a few used
to identify the indication of interest as coming from the first
user (Alice)), and first side information 7138, 7144 (e.g., buy).
First side information may include identification of a first leg of
the smart contract (e.g., buy or sell). In embodiments, additional
information, such as shown in FIG. 27D may also be included in an
indication of interest. For example, referring to FIG. 27C, a first
indication of interest 7134 may be sent by Alice (as the first
user) to Gemini (as the security token administrator). Alice's
indication of interest 7134 may include her user identification
number 7136, ID No. 12345 (as the first user identification
information), and information indicating that Alice would like to
buy 7138 (as the first side information).
[1015] In embodiments, the first indication of interest may further
include additional information such as, a first user public address
and/or first collateral information, to name a few. In embodiments,
such additional information may not be necessary to include in the
indication of interest because it may be included in the contract
parameters as published and thus implied. First collateral
information may be in stable value digital asset tokens (SVCoins).
For example, referring to FIG. 27D, a first indication of interest
7140 may be sent by Alice (as a first user) to Gemini (as the
security token administrator). Alice's indication of interest may
include: (1) her user identification number 7142, ID No. 12345 (as
the first user identification information); (2) information
indicating that Alice would like to buy 7144 (as the first side
information); Alice's Public Address 7146 (as the a first user
public address); and (4) information indicating a collateral 7148
of 100 Stable Value Coins (as the first collateral
information).
[1016] In embodiments, the second indication of interest may be a
second user response sent from a second user device 105b to
administrator system 6801. In embodiments, the second user device
105b may be associated with a second user (e.g. Bob). The second
indication of interest (e.g. second indication of interest 7150
described in connection with FIG. 27E or second indication of
interest 7156 described in connection with FIG. 27F) may include
second user identification information 7152, 7158 associated with
the second user (e.g. a name, user number, email address, to name a
few used to identify the indication of interest as coming from the
second user (Bob), and second side information (e.g. sell). The
second side information may include identification of a second leg
of the smart contract (e.g. buy or sell). In embodiments, the
second leg is different from the first leg. In embodiments,
additional information, such as shown in FIG. 27F, may also be
included in an indication of interest. For example, referring to
FIG. 27E, a second indication of interest 7150 may be sent by Bob
(as the second user) to Gemini (as the security token
administrator). Bob's indication of interest 7150 may include his
user identification number 7152, ID No. 54321 (as the second user
identification information), and information indicating 7154 that
Bob would like to sell (as the first side information). In some
embodiments, the second indication of interest my further include
additional information such as, a second user public address 7162
and/or second collateral information 7164, to name a few. The
second collateral information 7164 may be in stable value digital
asset tokens ("SVCoins"). In embodiments, the second indication of
interest may include the second user's digital signature which is
based on their private key which corresponds to their public key
which is associated with their public address. For example,
referring to FIG. 27F, a second indication of interest 7156 may be
sent by Bob (as the second user) to Gemini (as the security token
administrator). Bob's indication of interest 7156 may include: (1)
his user identification number 7158, ID No. 54321 (as the second
user identification information) or Alice's digital signature which
is based on her private key which corresponds to her public key
which is associated with her Public Address; (2) information
indicating that Bob would like to sell 7160 (as the second side
information); Bob's Public Address 7162 (as the second user public
address); and (4) information indicating a collateral 7164 of 100
Stable Value Coins (as the second collateral information). In
embodiments, Bob's indication of interest may include the Bob's
digital signature which is based on Bob's private key which
corresponds to Bob's public key which is associated with Bob's
Public Address.
[1017] In embodiments, step S7004 may further include the
administrator system may receive a third and fourth user responses
from a fourth user device and a fifth user device, for example. The
third user response, in some embodiments, may include fourth user
identification information associated with the fourth user. In
embodiments, the third user response may also include third side
information comprising identification of the first leg of the
contract. In embodiments, the third user response may be similar to
first indication of interest 7134 described in connection with FIG.
27C, first indication of interest 7140 described in connection with
FIG. 27D, second indication of interest 7150 described in
connection with FIG. 27E and/or second indication of interest 7156
described in connection with FIG. 27F, the descriptions of which
applying herein.
[1018] The fourth user response may include fifth user
identification information associated with the fifth user. In
embodiments, the fourth user response may also include fourth side
information comprising identification of the second leg of the
contract, the fourth side information being different than the
third side information. In embodiments, the fourth user response
may be similar to first indication of interest 7134 described in
connection with FIG. 27C, first indication of interest 7140
described in connection with FIG. 27D, second indication of
interest 7150 described in connection with FIG. 27E and/or second
indication of interest 7156 described in connection with FIG. 27F,
the descriptions of which applying herein.
[1019] Referring back to FIG. 26A, after receiving the first user
response (i.e. a first indication of interest) and the second user
response (i.e. a second indication of interest), In step S7006, the
administrator system 6801 matches the first user response with the
second user response. For example, referring to FIGS. 27C-27F,
administrator 6801 may match Alice with Bob because Alice wants to
buy and Bob would like to sell. In embodiments, such as embodiments
where more than one user has agreed to the contract provisions in
the published contract (as discussed above in connection with FIG.
28), matching may not be required and step S7006 may be
omitted.
[1020] In embodiments, such as the embodiments where a third user
response and fourth user response are received by the administrator
system, the third user response may be matched with the fourth user
response.
[1021] In step S7008, a stable value token smart contract
associated with a stable token 6807 and first smart contract
instructions 6807B associated with a first contract address 6807A
associated with the blockchain 6803 for the underlying digital
asset are provided. In embodiments, the first smart contract
instructions 6807B are saved in the blockchain 6803 for the
underlying digital asset. In embodiments, the first smart contract
instructions 6807B may include the stable value token smart
contract instructions 6807B described in connection with FIG. 25C,
the same description applying herein.
[1022] Referring back to FIG. 26A, In step S7010, a security token
smart contract associated with a security token 6805 and second
smart contract instructions 6805B associated with the blockchain
6803 for the underlying digital asset are provided. In embodiments,
the second smart contract instructions 6805B are saved in the
blockchain 6803 for the underlying digital asset. In embodiments,
the second smart contract instructions 6805B may include the
security token smart contract instructions 6805B described in
connection with FIG. 25B, the same description applying herein.
[1023] In embodiments, step S7008 and step S7010 may be performed
before step S7002, step S7004, and step S7006.
[1024] Referring back to FIG. 26A, the process may continue with
step S7012, in which the administrator system 6801 sets up a first
trade (e.g. trade001) between the first user (e.g. the user
associated with first user device 105a) and the second user (e.g.
the user associated with the second user device 105b) using the
security token smart contract 6805B on the underlying blockchain
6803 with collateral in the form of stable value digital assets
(i.e. stable value token 6807). Step S7012 is described in more
detail in connection with FIGS. 70B-D.
[1025] Referring to FIG. 26B, in embodiments, setting up the first
trade between the first user and the second user may begin at step
S7016, where the administrator system 6801 generates first trade
instructions for the security token smart contract 6805B. The first
trade instructions may include instructions to execute the first
trade between a first user public address associated with the first
user (e.g. the user associated with user device 105a) and a second
user public address associated with a second user (e.g. the user
associated with user device 105b). In embodiments, the first trade
is based at least on the contract terms from step S7002 (i.e. one
or more of the contract parameters discussed in connection with
FIG. 25A), the first user response from step S7004 (associated with
a received IOI--i.e. the IOI's described in connection with FIGS.
27C-27F), and the second user response from step S7004(associated
with another received IOI--i.e. the IOI's described in connection
with FIGS. 27E-27F).
[1026] In step S7018, the administrator system 6801 may generate
first hashed trade instructions, the first hashed trade
instructions being generated by applying a hash algorithm to the
first trade instructions. Examples of hash algorithms include MD 5,
SHA 1, SHA 256, RIPEMD, and Keccak-256 to name a few. Hash
algorithms take an input of any length and create an output of
fixed length, allowing the trade instructions to be detectable and
usable by administrators and users on the underlying blockchain.
However, applying a hash algorithm is not always necessary if trade
instructions are published ahead of time
[1027] In step S7020, the administrator system 6801 sends a first
transaction request from an administrator public address associated
with the administrator system 6801 to the second contract address
6805A via the underlying blockchain 6803. In embodiments, the first
transaction request, includes a first message which may include:
(1) the first hashed trade instructions; (2) a request to assign a
first trade identification to a first trade associated with the
hashed trade instructions. In embodiments, the first message may
include requests to assign a first trade identification to the
first trade associated with the hashed trade instructions and
include the first trade identification associated with the first
hashed trade instructions. In embodiments, the first transaction
request may further include first transaction fee information. The
first transaction fee information, in embodiments, may be for
miners on the blockchain 6803 to process the first transaction
request. The first transaction request may also be electronically
signed by an administrator private key. The administrator private
key may be mathematically related to the administrator public
address.
[1028] The process may continue with step S7022. In step S7022, the
administrator system 6801 obtains the first trade identification of
the first trade. In embodiments, the administrator system 6801 may
determine the first trade identification, as calculated by the
security token smart contract, by monitoring transactions on the
blockchain 6803 (as shown in connection with a step S7024 of FIG.
26B). In response to obtaining the first trade identification of
the first trade, the administrator system 6801 may notify the first
user (e.g. the user associated with user device 105a) and the
second user (e.g. the user associated with user device 105b) of the
first trade identification. In step S7026, the administrator system
6801 may send the first trade identification to the first user
device 105a associated with the first user. Similarly, in step
S7028, the administrator system 6801 sends the first trade
identification to the second user device 105b associated with the
second user.
[1029] In embodiments, as shown In step S7030, the first user
device 105a may send a second transaction request from a first user
public address (the first user public address being associated with
the first user and the first user device 105a) to the first
contract address 6807A via the underlying blockchain 6803. The
second transaction request may include a second message, the second
message including requests to the stable value token smart contract
6807B regarding a first transfer of a first amount of collateral.
In embodiments, the second message may include the first trade
information. In embodiments, the second transaction request may
include second transaction fee information. The second transaction
fee information may be for miners on the blockchain 6803 to process
the second transaction request. In embodiments, the second message
may also include a transfer request to the stable value smart
contract to transfer the first amount of collateral in the form of
stable value digital asset tokens 6807 from the first user public
address to the second contract address 6805A. The transfer request,
in embodiments, will be executed upon receipt of a first collateral
request from the second contract address 6805A. In embodiments, the
transfer request included in the second message may be executed
upon receipt of a first collateral request from the administrator
system 6801. The second transaction request is also electronically
signed by a first user private key. The first user private key may
be mathematically related to the first user public address.
[1030] In embodiments, the process described in FIG. 26B may
continue with the process shown in connection with FIG. 26C. In
embodiments, as shown In step S7032, the second user device may
send a third transaction request from a second user public address
(associated with the second user and the second user device 105b)
to the second contract address 6805A via the underlying blockchain
6803. The third transaction request may include a third message
including a second transfer request to the stable value token smart
contract 6807B regarding a second transfer of the second amount of
collateral from the second user public address to the second
contract address 6807A. In embodiments, the third transaction
request may further include third transaction fee information. The
third transaction fee information, in embodiments, may be for
miners on the blockchain 6803 to process the third transaction
request. The second transfer request of the third message, in
embodiments, will be executed upon receipt of a second collateral
request from the second contract address 6805A. Alternatively, the
second transfer request of the third message will be executed upon
receipt of a second collateral request from the administrator
system 6801. The third transaction request may also be
electronically signed by a second user private key. The second user
private key may is mathematically related to the second user public
address.
[1031] The process may continue with a step S70121. In step S7034,
the administrator system 6801 monitors transactions of the stable
value digital asset tokens 6807 on the blockchain 6803 to determine
that the second contract address 6805A has received at least the
following: (1) the first amount of collateral in stable value
digital asset tokens from the first user (e.g. the user associated
with user device 105a); and (2) the second amount of collateral in
stable value digital asset tokens from the second user (e.g. the
user associated with user device 105b). In embodiments, the
administrator system 6801 may further monitor the first contract
address 6807A to determine whether the first amount of collateral
is received at the second contract address 6805A and whether the
second amount of collateral is received at the second contract
address 6805A (as shown in connection with a step S7036 of FIG. 26C
and step S7038 of FIG. 26C).
[1032] Alternatively, the administrator system 6801 may receive a
collateral confirmation message confirming that the first amount of
collateral and the second amount of collateral are received by the
second contract address 6805A (as shown in connection with a step
S7040 of FIG. 26C). In embodiments, either the first amount of
collateral, the second amount of collateral, or both may not be
received at the second contract address. If either or both are not
received, in embodiments, the collateral confirmation message may
indicate a lack of collateral, or the collateral confirmation
message may not be sent.
[1033] Upon determining that the first amount of collateral from
the first user (e.g. the user associated with user device 105a) and
the second amount of collateral from the second user (e.g. the user
associated with user device 105b) have both been received by the
second contract address 6805A, In step S7042, the administrator
system 6801 may send a fourth transaction request from the
administrator public address to the second contract address 6805A
via the underlying blockchain 6803. The fourth transaction request
may include a fourth message including the first trade instructions
and the first trade identification. In embodiments, the fourth
transaction request may further include fourth transaction fee
information. The fourth transaction fee information, in
embodiments, may be for miners on the blockchain 6803 to process
the fourth transaction request. The fourth transaction request may
also be electronically signed by the administrator private key.
[1034] In embodiments, the second contract address 6805A may
further include modules with instructions to: (1) generate a first
collateral request when the third message is received by the second
contract address 6805A; (2) send the first collateral request to
the first contract address 6807A associated with the stable value
token smart contract; (3) generate a second collateral request when
the third message is received by the first contract address 6807A;
(4) send the first collateral request to the first contract address
6807A associated with the stable value digital asset token smart
contract; confirming that the first amount of collateral from the
first user (e.g. a user associated with user device 105a) and the
second amount of collateral from the second user (e.g. a user
associated with user device 105b) has been received by the second
contract address; and (5) sending a collateral confirmation message
to the administrator public address.
[1035] Upon receiving the confirmation message, the administrator
system 6801 may send a fourth transaction request from the
administrator public address to the second contract address 6805A
via the underlying blockchain 6803. The fourth transaction message
may include a fourth message comprising first trade instructions
and the first trade identification.
[1036] Referring now to FIG. 26D, in embodiments, step S7012 may
being with a step S7042. In step S7042, the administrator system
6801 may send a first transaction request from the administrator
public address to the second contract address 6805A via the
underlying blockchain 6803. The first transaction request, in
embodiments, may include a first message comprising requests to
create a first trade between the first user and the second user in
accordance with the security token smart contract 6805B. In
embodiments, the first transaction request may further include
first transaction fee information. The first transaction fee
information, in embodiments, may be for miners on the blockchain
6803 to process the first transaction request. The first
transaction request may also be electronically signed by the
administrator private key. The administrator private key is
mathematically related to the administrator public address.
[1037] In embodiments, as shown In step S7044, the first user
device 105a may then send a second transaction request from a first
user public address (the first user public address being associated
with the first user and the first user device 105a) to the first
contract address 6807A via the underlying blockchain 6803. The
second transaction request may include a second message, the second
message authorizing the stable value token smart contract 6807B to
accept a request to transfer a first amount of collateral from the
first user public address to the second contract address 6805A. In
embodiments, the second transaction request may further include
second transaction fee information. The second transaction fee
information, in embodiments, may be for miners on the blockchain
6803 to process the second transaction request. The second
transaction request may be electronically signed by the first user
private key. The first user private key is mathematically related
to the first user public address.
[1038] The process may continue at step S7046. At a step S7046, the
second user device may send a third transaction request from a
second user public address (associated with the second user and the
second user device 105b) to the second contract address 6805A via
the underlying blockchain 6803. The third transaction request may
include a third message authorizing the stable value digital asset
smart contract 6807B to accept a request to transfer a second
amount of collateral from the second user public address to the
second contract address 6805A. In embodiments, the third
transaction request may further include third transaction fee
information. The third transaction fee information, in embodiments,
may be for miners on the blockchain 6803 to process the third
transaction request. The third transaction request may be
electronically signed by the second user private key. The second
user private key is mathematically related to the second user
public address.
[1039] In step S7048, the administrator system 6801 may send a
fourth transaction request from the administrator public address to
the first contract address 6807A via the underlying blockchain
6803. The fourth transaction request may include a fourth message
including requests to: (1) transfer of the first amount of
collateral of stable value digital asset tokens from the first user
public address to the second contract address 6805A; and (2)
transfer of a second amount of collateral of stable value digital
asset tokens 6807 from the second user public address to the second
contract address 6805A. The fourth transaction request may also be
electronically signed by the administrator private key.
[1040] Alternatively, the second contract address 6805A may send a
fourth transaction request to the first contract address 6807A via
the underlying blockchain 6803. The fourth transaction request may
similarly include a fourth message including requests to: (1)
transfer of the first amount of collateral of stable value digital
asset tokens 6807 from the first user public address to the second
contract address 6805A; and (2) transfer of a second amount of
collateral of stable value digital asset tokens from the second
user public address to the second contract address 6805A.
[1041] In alternative embodiments, steps 57010 and 57012 (and
accompanying substeps described above in connection with FIGS.
70B-D) may be replaced by a method of generating the security token
contract associated with the security token 6805 associated with
blockchain 6803 for the underlying digital asset. The method, in
embodiments, may begin by an administrator 6801 generating the
security token smart contract associated with a security token 6805
and second smart contract instructions 6805B associated with a
second smart contract address 6805A associated with the blockchain
6803 for the underlying digital asset. In embodiments, the second
smart contract instructions 6805B are saved in the blockchain 6803
for the underlying digital asset.
[1042] The second smart contract instructions 6805B may include one
or more of the following: (1) first trade instructions for the
security token smart contract; (2) fifth authorization instructions
regarding transferring security tokens (which may be included in
the transfer security tokens module 6920); (3)sixth authorization
instructions regarding destroying security tokens (which may be
included in the destroy security tokens module 6922); (4) seventh
authorization instructions regarding transferring stable value
tokens to the second contract address (which may be included in the
authorize instructions module 6926); (5) eighth authorization
instructions regarding transferring stable value tokens from the
second contract address (which may be included in the authorize
instructions module 6926); (6) calculating instructions regarding
calculating excess collateral(which may be included in the
calculate excess collateral module 6928); (7) generating collateral
information instructions regarding excess collateral (which may be
included in the generate collateral information message module
6930); and (8) sending collateral information message instructions
regarding excess collateral (which may be included in the send
collateral information message module 6932). In embodiments, the
first trade instructions may include execution instructions to
execute a first trade between the first user and the second user.
The first trade, in embodiments, may be based on at least (1) the
contract request or proposal and (2) the first user response.
[1043] In embodiments, once the security token contract is
generated by an administrator 6801, the administrator 6801 may send
the security token smart contract and associated second smart
contract instructions 6805B to the second smart contract address
6805A via the blockchain 6803 for the underlying digital asset.
[1044] In embodiments, the first trade instructions may be
implemented via the blockchain 6803 for the underlying digital
asset by computers systems among the plurality of geographically
distributed computer systems in the peer-to-peer network.
[1045] Referring back to FIG. 26A, the process of FIG. 26A may
continue with step S7014. In step S7014, excess collateral from the
first trade may be collected from the security token contract. Step
S7014 is described in more detail in connection with FIGS.
70E-F.
[1046] Referring to FIG. 26E, in embodiments, collecting excess
collateral may begin at step S7050. In step S7050, the
administrator system 6801 may send a fifth transaction request from
the administrator public address to the second contract address
6805A via the underlying blockchain 6803. In embodiments, the fifth
transaction request may include a fifth message comprising requests
for the security token smart contract 6805B to determine and
distribute excess collateral for the first trade in accordance with
the security token smart contract 6805B and the first trade
instructions. The fifth transaction request may be electronically
signed by the administrator private key. The administrator private
key is mathematically related to the administrator public
address.
[1047] In response to the requests contained in the fifth message,
as shown in step S7052, the security token smart contract 6805B
sends a sixth transaction request from the second contract address
6805A to an oracle address associated with an oracle smart contract
on the blockchain 6803 associated with an oracle interface in
contact with a trusted third party database. The sixth transaction
request, in embodiments, may include a sixth message to obtain
first benchmark data from the trusted third party database. In
response to sending the sixth transaction request, in step S7054,
the security token smart contract 6805B may receive a callback
message from the oracle interface including the first benchmark
information. In embodiments, access to the trusted third party
database through the oracle smart contract may be limited to
certain authorized or approved addresses on the blockchain. In
embodiments, as described further below, a whitelist of authorized
(or approved) requesting addresses may be provide in which the
first benchmark information is provided only in response to
requests from an authorized address. In embodiments, the whitelist
of authorized requesting addresses may be updated. In embodiments,
the administrator system may update the whitelist of authorized
requesting addresses to reflect the address of the security token
contract that is provided using the process of the present
application.
[1048] In embodiments, the whitelist of authorized addresses may be
included at the oracle smart contract address. In embodiments, the
oracle smart contract address may include authorization
instructions to request the first contract address only when the
requester address is one of the addresses on the whitelist. In
embodiments, the oracle smart contract may include authorization
instructions related to an update key pair for updating the
whitelist of authorized addresses to allow for the white list to be
updated.
[1049] In embodiments, the whitelist of authorized addresses may be
provided in memory element associated with the trusted third party
database. In embodiments, the trusted third party database will not
provide the first benchmark information to the oracle contract
unless the requester address is included in the whitelist of
authorized addresses.
[1050] In response to receiving a callback message, in step S7056,
the security token smart contract 6805B executes instructions to:
(1) store the first benchmark information and (2) calculate the
excess collateral for the first user (e.g. the user associated with
user device 105a) and the second excess collateral for the second
user (e.g. the user associated with user device 105b) by using the
first trade instructions and the first benchmark information. In
embodiments, the first excess collateral is the first amount of
collateral less the difference between the first benchmark
information and the inception value, to the extent it is greater
than zero. In embodiments, the second excess collateral is the
second amount of collateral less the difference between the
inception value and the first benchmark information, to the extent
it is greater than zero.
[1051] To the extent that the first excess collateral is greater
than zero or the second excess collateral is greater than zero, in
step S7058, the security token smart contract 6805B sends a seventh
transaction request from the second contract address 6805A to the
first contract address 6807A via the underlying blockchain 6803.
The seventh transaction request, in embodiments, may include a
seventh message requesting the stable value token smart contract
6807B to transfer: (1) the first excess collateral in stable value
digital asset token from the second contract address 6805A to the
first user public address (associated with the first user and user
device 105a), to the extent the first excess collateral is greater
than zero; and (2) the second excess collateral in stable value
digital asset token from the second contract address 6805A to the
second user public address (associated with the second user and
user device 105b).
[1052] Referring to FIG. 26F, in embodiments, collecting excess
collateral may begin at step S7060 where an oracle service sends a
fifth transaction request from an oracle address associated with an
oracle interface to the second contract address 6805A via the
underlying blockchain 6803. In embodiments, the fifth transaction
request may include a fifth message comprising first benchmark
information. In response to receiving the fifth message, in step
S7062 the security token contract 6805B executes instructions to
store first benchmark information.
[1053] The process in FIG. 26F may continue at step S7064. In step
S7064, the administrator system 6801 may send a sixth transaction
request from the administrator public address to the second
contract address 6805A via the underlying blockchain 6803. The
sixth transaction request, in embodiments, may include a sixth
message comprising requests to the security token smart contract
6805B to determine and distribute excess collateral for the first
trade in accordance with the security token smart contract 6805B
and the first contract instructions. The sixth transaction request
may also be electronically signed by an administrator private key
(located in key information data base 6801C of FIG. 24). The
administrator private key is mathematically related to the
administrator public address. In embodiments, the sixth transaction
request may be sent by user device 105a from the first user public
address (associated with a first user and user device 105a) to the
second contract address 6805A. In embodiments, where the sixth
transaction request is sent by user device 105a, the sixth
transaction request may also be electronically signed by a first
user private key. The first user private key is mathematically
related to the first user public address. Furthermore, in
embodiments, the sixth transaction request may be sent by user
device 105b from the second user public address (associated with a
second user and user device 105b) to the second contract address
6805A. In embodiments, where the sixth transaction request is sent
by user device 105b, the sixth transaction request may also be
electronically signed by a second user private key. The second user
private key is mathematically related to the second user public
address.
[1054] In response to the requests contained in the sixth message,
in step S7014'D, the security token smart contract 6805B executes
instructions via the blockchain 6803 to calculate first excess
collateral for the first user (e.g. a user associated with user
device 105a) and second excess collateral for the second user (e.g.
a user associated with user device 105b) using the first trade
instructions and the first benchmark information. In embodiments,
the first excess collateral is the first amount of collateral less
the difference between the first benchmark information and the
inception value, to the extent it is greater than zero. In
embodiments, the second excess collateral is the second amount of
collateral less the difference between the inception value and the
first benchmark information, to the extent it is greater than
zero.
[1055] To the extent that the first excess collateral is greater
than zero or the second excess collateral is greater than zero, in
step S7014'E, the security token smart contract 6805B sends a
seventh transaction request from the second contract address 6805A
to the first contract address 6807A via the underlying blockchain
6803. The seventh transaction request, in embodiments, may include
a seventh message requesting the stable value token smart contract
6807B to transfer: (1) the first excess collateral in stable value
token from the second contract address 6805A to the first user
public address (associated with the first user and user device
105a), to the extent the first excess collateral is greater than
zero; and (2) the second excess collateral in stable value token
from the second contract address 6805A to the second user public
address (associated with the second user and user device 105b). As
in step S7014E, if there is excess collateral, the second contract
address 6805A sends the excess collateral to the user of which that
excess collateral belongs.
[1056] In embodiments, such as the embodiments where a third user
response and fourth user response are received by the administrator
system and matched, the administrator system may set up a second
trade between the fourth user and the fifth user. This process of
setting up a trade between two users may be similar to the process
described in connection with FIGS. 26B-26D, the same description
applying herein.
[1057] In embodiments, the steps within the process described above
in connection with FIGS. 26A-26F may be rearranged or omitted.
[1058] In embodiments, a separate security token smart contract may
be generated and published to the underlying blockchain for each
separate trade.
[1059] For example, in embodiments, generating a security token
smart contract between a first user and a second user may be
implemented, in accordance with the following example. In
embodiments, generating a security token smart contract between a
first user and a second user may begin with an administrator system
associated with an administrator 6809 of a security token smart
contract receiving a contract proposal. In embodiments, the
security token smart contract is maintained on a distributed public
transaction ledger maintained by a plurality of geographically
distributed computer systems in a peer-to-peer network in the form
of a blockchain 6803 of an underlying digital asset. In
embodiments, the underlying digital asset may be a digital
math-based asset, Ether, or Neo, to name a few. In embodiments, the
contract proposal includes: first user information associated with
a first user device 105a that is associated with a first user; and
first contract information including at least the following
contract parameters 6801B: an inception date 6902; an inception
value 6904; at least one benchmark 6906; a contract duration 6908;
at least one collateral requirement 6910; a notional value of the
smart contract 6912; and first side information, including
identification of a first leg of the contract (e.g. the side
information including a leg of a contract described in FIGS.
27C-27F--ref nos. 7138, 7144, 7154, 7160 respectively). In
embodiments, the first user information further includes a first
user public address (e.g., Alice Public Address 7146 described
above in reference to FIG. 27D) associated with the blockchain 6803
of the underlying digital asset. In embodiments, the first user
public address corresponds to a first user private key that is
mathematically related to the first user public address. In
embodiments, the first contract information further includes at
least one of the following: derivative type information; early
termination rules 6914; a second benchmark 6916; asset
identification information; pricing model information; and
volatility information. In embodiments, the first contract
information further includes first collateral information in stable
value tokens (e.g., 100 Stable Value Coins 7148 described above in
reference to FIG. 27D). In embodiments, the first contract
information further includes second collateral information in
stable value tokens. In embodiments, the first contract information
includes first transaction fee information. In embodiments, the
administrator system may generate graphical user interface
information including at least one prompt for the first user to
provide the contract proposal. The administrator system may then
send the graphical user interface information to the first user
device. In embodiments, the administrator system may then receive
the contract proposal in response to the at least one prompt.
[1060] In embodiments, the method continues with the administrator
system receiving at least one indication of interest (e.g., second
indication of interest 7150 described above in reference to FIG.
27E). In embodiments, the at least one indication of interest
includes at least a first user response, from a second user device
105b associated with a second user. In embodiments, the first user
response includes second user information associated with the
second user. In embodiments, the second user information further
includes a second user public address (e.g., Bob Public Address
7162) associated with the blockchain 6803 of the underlying digital
asset. In embodiments, the second user public address corresponds
to a second user private key that is mathematically related to the
second user public address. In embodiments, the first user response
further includes second side information which may include an
identification of a second leg of the contract (e.g. the side
information including a leg of a contract described in FIGS.
27C-27F--reference numbers 7138, 7144, 7154, and 7160
respectively).
[1061] In embodiments, the method continues with the administrator
system matching the first contract information and the first user
response. Matching, by the administrator system, may be similar to
S7006 of FIG. 26A.
[1062] In embodiments, the method continues with an administrator
system providing a stable value token smart contract associated
with a stable value token 6807 and first smart contract
instructions 6807B for a digital asset token. The digital asset
token, in embodiments, may be associated with a first smart
contract address 6807A that may be associated with the blockchain
6803 for the underlying digital asset. In embodiments, the first
smart contract instructions 6807B are saved in the blockchain 6803
for the underlying digital asset. In embodiments, the first smart
contract instructions 6807B include: first authorization
instructions regarding creating stable value tokens (which may be
included in the create stable value token module 6934); second
authorization instructions regarding transferring stable value
tokens(which may be included in the transfer stable value token
module 6936); third authorization instructions regarding destroying
stable value tokens (which may be included in the destroy stable
value token module 6938); and fourth authorization instructions
regarding functions associated with the stable value token (which
may be included in the authorization instruction module 6940). In
embodiments, the first smart contract instructions of the first
stable value smart contract are associated with more than one smart
contract address. For example, Smart Contract Address 6807A may be
associated with a plurality of smart contract addresses associated
with the blockchain 6803 for the underlying digital asset.
[1063] In embodiments, the method continues with the administrator
system generating the security token smart contract, which may be
associated with a security token 6805 and second smart contract
instructions 6805B which may be associated with a second smart
contract address 6805A which may be associated with the blockchain
for the underlying digital asset. In embodiments, the second smart
contract instructions 6805B are saved in the blockchain 6803 for
the underlying digital asset. In embodiments, the second smart
contract instructions 6805B include: first trade instructions for
the security token smart contract (which may be similar to step
S7016 described above in reference to FIG. 26B), fifth
authorization instructions regarding transferring security tokens
(which may be included in transfer security tokens module 6920);
sixth authorization instructions regarding destroying security
tokens (which may be included in destroy security tokens module
6922); seventh authorization instructions regarding transferring
stable value tokens to the second contract address (which may be
included in authorize instructions module 6926); eighth
authorization instructions regarding transferring stable value
tokens from the second contract address (which may be included in
authorize instructions module 6926); and calculating instructions
regarding calculating excess collateral (which may be included in
calculate excess collateral module 6928). In embodiments, the first
trade instructions include execution instructions to execute a
first trade between the first user and the second user (which may
be included in authorize instructions module 6926). In embodiments,
the first trade is based on at least: the contract proposal and the
first user response.
[1064] In embodiments, the method continues with the administrator
system sending the security token smart contract and associated
second smart contract instructions. In embodiments, the security
token smart contract and associated second smart contract
instructions 6805B may be sent via the blockchain 6803 for the
underlying digital asset to the second smart contract address
6805A.
[1065] In embodiments, the method may continue with the second
smart contract address 6805A receiving a first amount of
collateral. In embodiments, the first amount of collateral may be a
first amount of stable value tokens associated with the first user
as collateral. In embodiments, the first amount of stable value
tokens associated with the first user is based on the at least one
collateral requirement 6910. In embodiments, the first user device
105a may send a first message. The first message may include a
request to transfer the first amount of collateral from the first
user public address to the second smart contract address. In
embodiments, the first message may be sent via the underlying
blockchain 6803 from the first user public address associated with
the underlying blockchain 6803 to the first smart contract address
6807A associated with the underlying blockchain 6803. In
embodiments, the first user device 105a may send a second message
to the first smart contract address 6807A. The second message may
include authorization for the security token smart contract to
request a transfer of the first amount of collateral. In
embodiments, the administrator system may send a third message
including instructions to send a request from the second smart
contract address 6805A to the first smart contract address 6807A.
The request, in embodiments, may be for the first amount of
collateral to be transferred from the first user public address to
the second smart contract address 6805A. In embodiments, the third
message is sent by the administrator system via the underlying
blockchain 6803 to the second smart contract address 6805A.
[1066] In embodiments, the method may continue with the second
smart contract address 6805A receiving a second amount of
collateral. In embodiments, the second amount of collateral may be
a second amount stable value tokens associated with the second user
as collateral. In embodiments, the second amount of stable value
tokens associated with the second user is based on the at least one
collateral requirement 6910. In embodiments, the second user device
105b may send a fourth message including a request. In embodiments,
the request may be to transfer the second amount of collateral from
the second user public address to the second smart contract address
6805A. In embodiments, the fourth message may be sent via the
underlying blockchain 6803 from the second user public address
associated with the underlying blockchain 6803 to the first smart
contract address 6807A associated with the underlying blockchain
6803. In embodiments, the second user device 105b may send a fifth
message to the first smart contract address 6807A. The fifth
message, in embodiments, may include authorization for the security
token smart contract to request a transfer of the second amount of
collateral via the blockchain 6803. In embodiments, the
administrator system may send a sixth message. The sixth message,
in embodiments, may include instructions to send a request. The
request, in embodiments, may be for the second amount of collateral
to be transferred from the second user public address to the second
smart contract address 6805A. In embodiments, the sixth message is
sent via the underlying blockchain 6803 to the second smart
contract address 6805A.
[1067] In embodiments, the first trade instructions are implemented
via the blockchain for the underlying digital asset by computer
systems among the plurality of geographically distributed computer
systems in the peer-to-peer network. In embodiments, the first
trade instructions are implemented as a result of a message sent
from the administrator system via the blockchain 6803 to the second
smart contract address 6805A.
[1068] In embodiments, the method may continue with the first
collateral amount being recalculated based on the at least one
collateral requirement 6910 and current benchmark information (this
may be similar to steps S6310 and S6311, both described above in
reference to FIG. 63C). In embodiments, the recalculation may be
performed by the first user device 105a. In embodiments, the
recalculation is performed by the administrator system. In
embodiments, a first additional collateral amount may be determined
based on a difference between the recalculated first collateral
amount and the first collateral amount. The first additional
collateral amount may then be received at the second smart contract
address 6805A. In embodiments, the first additional collateral may
not be received. In embodiments, the administrator system may
generate an alert. The alert, in embodiments, may include the first
additional collateral amount. Once generated, the administrator
system may send the alert to the first user device 105a. In
embodiments, the alert may be generated and sent by security token
smart contract to the first user device 105a (e.g., using the
generate collateral information message module 6930 and the send
collateral information message module 6932). Once the alert
regarding the first additional collateral amount is received by the
first user device 105a, the method may continue with the
administrator system monitoring the second contract address 6805A
on the blockchain 6803 associated with the underlying digital asset
(this may be similar to step S7034 described above in reference to
FIG. 26C). The administrator system may then, in embodiments,
determine whether the first additional collateral amount is
received by the second contract address 6805A (this may be similar
to step S7034 described above in reference to FIG. 26C). If the
first additional collateral is not received by the second contract
address 6805A, the administrator system may generate a default
notification. The default notification may be sent by the
administrator system to at least one of the first user device 105a,
the second user device 105b, and the second smart contract address
6805A. In embodiments, the default notification may be generated
and sent by security token smart contract to at least one of the
first user device 105a and the second user device 105b (e.g., using
the generate collateral information message module 6930 and the
send collateral information message module 6932). After the default
notification is sent, the administrator system, in embodiments, may
generate a seventh message. The seventh message, in embodiments,
may include a request to transfer the first collateral amount and
the second collateral amount in accordance with the first trade
instructions. The seventh message may be sent by the administrator
system to the second smart contract address 6805A. In embodiments,
the transfers of the first collateral amount and the second
collateral amount are implemented by the plurality of
geographically distributed computer systems in the peer-to-peer
network.
[1069] In embodiments, the method may continue with the second
collateral amount being recalculated based on the at least one
collateral requirement 6910 and current benchmark information (this
may be similar to steps 56310 and 56311, both described above in
reference to FIG. 63C). In embodiments, the recalculating step is
performed by the second user device 105b. In embodiments, the
recalculating step is performed by the administrator system. In
embodiments, a second additional collateral amount may be
determined based on a difference between the recalculated second
collateral amount and the second collateral amount. In embodiments,
the second additional collateral amount is received at the second
smart contract address 6805A. In embodiments, the second additional
collateral may not be received and the administrator system may
generate an alert. The alert, in embodiments, may include the
second additional collateral amount. Once generated, the
administrator system may send the alert to the second user device
105b. In embodiments, the alert may be generated and sent by
security token smart contract to the second user device 105b (e.g.,
using the generate collateral information message module 6930 and
the send collateral information message module 6932). Once the
alert regarding the second additional collateral amount is received
by the second user device 105b, the method may continue with the
administrator system monitoring the second smart contract address
6805A on the blockchain 6803 associated with the underlying digital
asset (this may be similar to step S7034 described above in
reference to FIG. 26C). The administrator system may monitor the
second smart contract address 6805A to determine whether the second
additional collateral amount is received by the second contract
address (this may be similar to step S7034 described above in
reference to FIG. 26C). If the administrator system determines that
the second additional collateral amount is not received by the
second smart contract address 6805A, the administrator system may
generate a default notification. The default notification may be
sent by the administrator system to at least one of: the first user
device 105a, the second user device 105b, and the second smart
contract address 6805A. In embodiments, the default notification
may be generated and sent by security token smart contract to at
least one of the first user device 105a and the second user device
105b (e.g., using the generate collateral information message
module 6930 and the send collateral information message module
6932). After sending the default notification, the administrator
system may generate an eighth message. The eighth message, in
embodiments, may include a request to transfer the first collateral
amount and the second collateral amount in accordance with the
first trade instructions. The eighth message, In embodiments, may
be sent by the administrator system to the second smart contract
address 6805A, where transfers of the first collateral amount and
the second collateral amount are implemented by the plurality of
geographically distributed computer systems in the peer-to-peer
network.
[1070] In embodiments, the method may include the administrator
system determining, at the end of the contract duration, a payout
amount based on at least the first trade instructions. The payout
instructions may be generated by the administrator system. In
embodiments, the payout instructions may be based at least on the
first side information and the second side information (e.g. the
first and/or second side information including a leg of a contract
described in FIGS. 27C-27F--ref nos. 7138, 7144, 7154, 7160
respectively). The administrator system may, in embodiments, send
the payout instructions to the second contract address 6805A via
the blockchain 6803 for the underlying digital asset. The payout
instructions may provide the payout amount to one of the first user
public address and the second user public address. The payout
amount, in embodiments, being based on at least the first trade
instructions. In embodiments, the payout instructions are
implemented by the plurality of geographically distributed computer
systems in the peer-to-peer network.
[1071] In embodiments, the method may include the administrator
system collecting excess collateral from the first trade (this may
be similar to S7014 described above in reference to FIGS. 26A, 26E,
and 26F). The administrator system may collect excess collateral by
first sending a ninth message to the second smart contract address
6805A via the underlying blockchain 6803 for the underlying digital
asset. The ninth message may include, in embodiments, requests for
the security token to: determine first excess collateral for the
first trade in accordance with the security token smart contract
(this may be similar to S7014 described above in reference to FIGS.
26A, 26E, and 26F) and the first trade instructions; determine
second excess collateral for the first trade in accordance with the
security token smart contract and the first trade instructions
(this may be similar to S7014 described above in reference to FIGS.
26A, 26E, and 26F); distribute the first excess collateral for the
first trade in accordance with the security token smart contract
and the first trade instructions to the first user address (this
may be similar to S7014 described above in reference to FIGS. 26A,
26E, and 26F); and distribute the second excess collateral for the
first trade in accordance with the security token smart contract
and the first trade instructions to the second user address (this
may be similar to S7014 described above in reference to FIGS. 26A,
26E, and 26F).
[1072] In embodiments, the administrator system may return the
remaining collateral from the first trade (this may be similar to
S7014 described above in reference to FIGS. 26A, 26E, and 26F). The
remaining collateral, in embodiments, may be from the security
token smart contract. In embodiments, returning the remaining
collateral may begin by the administrator system sending a tenth
message to the second smart contract address 6805. The tenth
message, in embodiments, may include requests for the security
token smart contract to: determine first remaining collateral for
the first trade in accordance with the security token smart
contract and the first trade instructions (e.g. using calculate
excess collateral module 6928); determine second remaining
collateral for the first trade in accordance with the security
token smart contract and the first trade instructions (e.g. using
calculate excess collateral module 6928); distribute the first
remaining collateral for the first trade in accordance with the
security token smart contract and the first trade instructions; and
distribute the second remaining collateral for the first trade in
accordance with the security token smart contract and the first
trade instructions (this may be similar to S7014 described above in
reference to FIGS. 26A, 26E, and 26F).
[1073] In embodiments, a first benchmark value 6906 may be
determined. The first benchmark value 6906 may be determined by the
security token smart contract sending, via the blockchain 6803 for
the underlying digital asset, a request. The request may be sent
from the second smart contract address 6805A to an oracle smart
contract at a third contract address associated with the blockchain
6803 for the underlying digital asset (this may be similar to S7014
described above in reference to FIGS. 26A, 26E, and 26F). The
oracle smart contract may be associated with an oracle interface in
contact with an authorized third party database. The request may
include an eleventh message (this may be similar to S7014 described
above in reference to FIGS. 26A, 26E, and 26F). The eleventh
message may include a request to obtain first benchmark value 6906
(this may be similar to S7014 described above in reference to FIGS.
26A, 26E, and 26F). In response to the eleventh message, the oracle
smart contract may send the first benchmark value 6906 to the
security token smart contract (this may be similar to S7014
described above in reference to FIGS. 26A, 26E, and 26F). In
response to receiving the first benchmark value, the security token
smart contract may execute instructions to store the first
benchmark value 6906.
[1074] In the case where the first excess collateral is greater
than zero the first excess collateral may be calculated for the
first user (this may be similar to S7014 described above in
reference to FIGS. 26A, 26E, and 26F). In the case where the second
excess collateral is greater than zero, the second excess
collateral may be calculated for the second user (this may be
similar to S7014 described above in reference to FIGS. 26A, 26E,
and 26F). The first and second excess collateral, in embodiments,
may be calculated using the first trade instructions and the first
benchmark information 6906 (this may be similar to S7014 described
above in reference to FIGS. 26A, 26E, and 26F). Once the excess
collateral is calculated, the second smart contract address may
send a twelfth message to the first smart contract address. The
twelfth message may include a request for the stable value token
smart contract to transfer the excess collateral--the first excess
collateral being requested to transfer if greater than zero and the
second excess collateral being requested to transfer if greater
than zero (this may be similar to S7014 described above in
reference to FIGS. 26A, 26E, and 26F).
[1075] Now that embodiments of the present invention have been
shown and described in detail, various modifications and
improvements thereon can become readily apparent to those skilled
in the art. Accordingly, the exemplary embodiments of the present
invention, as set forth above, are intended to be illustrative, not
limiting. The spirit and scope of the present invention is to be
construed broadly.
* * * * *
References