Database system public trust ledger multi-owner token architecture

1. A method implemented at a database system, the method comprising:

providing, by a database processor, computing services to a plurality of tenants of the database system via the internet;

receiving, by the database processor, from a client machine a request to execute an action related to a smart contract owned by a synthetic public trust ledger party and recorded on a public trust ledger external to the database system;

identifying, by the database processor, a database system account associated with the requested action and linked with a tenant of the plurality of tenants;

retrieving, by the database processor, from a table within the database system one or more synthetic public trust ledger party rules authorizing a plurality of database system accounts to perform a plurality of actions related to the smart contract;

determining, by the database processor, that the database system account is authorized to perform the action based on the one or more rules;

retrieving, by the database processor, one or more private keys for the synthetic public trust ledger account from the database system;

transmitting, by a ledger API, to a replica node of a public trust ledger external to the database system a ledger request to perform the action, the request authenticating the synthetic public trust ledger account to the replica node via the one or more private keys;

receiving, by the ledger API, from the replica node a ledger response indicating that the public trust ledger has been updated to reflect successful execution of the action;

updating, by the database processor, one or more records within the database system to reflect successful execution of the action; and

transmitting, by the database processor, to the client machine a response message indicating that the action has been performed.

2. The method recited in claim 1 , wherein the database system account is an owner of the smart contract.

3. The method recited in claim 1 , wherein the database system account is identified in the synthetic public trust ledger party as a subordinate party.

4. The method recited in claim 1 , wherein one or more private keys are stored within the database system.

5. The method recited in claim 1 , wherein the action transfers a token from a first party to a second party.

6. The method recited in claim 1 , wherein the action mints a fungible token.

7. The method recited in claim 1 , wherein the action mints a non-fungible token.

8. The method recited in claim 1 , wherein the action updates a definition stored in the public trust ledger and reflecting the one or more synthetic public trust ledger party rules.

9. One or more non-transitory computer readable media having instructions stored thereon for performing a method implemented at a database system, the method comprising:

providing, by a database processor, computing services to a plurality of tenants of the database system via the internet;

receiving, by the database processor, from a client machine a request to execute an action related to a smart contract owned by a synthetic public trust ledger party and recorded on a public trust ledger external to the database system;

identifying, by the database processor, a database system account associated with the requested action and linked with a tenant of the plurality of tenants;

retrieving, by the database processor, from a table within the database system one or more synthetic public trust ledger party rules authorizing a plurality of database system accounts to perform a plurality of actions related to the smart contract;

determining, by the database processor, that the database system account is authorized to perform the action based on the one or more rules;

retrieving, by the database processor, one or more private keys for the synthetic public trust ledger account from the database system;

transmitting, by a ledger API, to a replica node of a public trust ledger external to the database system a ledger request to perform the action, the request authenticating the synthetic public trust ledger account to the replica node via the one or more private keys;

receiving, by the ledger API, from the replica node a ledger response indicating that the public trust ledger has been updated to reflect successful execution of the action;

updating, by the database processor, one or more records within the database system to reflect successful execution of the action; and

transmitting, by the database processor, to the client machine a response message indicating that the action has been performed.

10. The one or more non-transitory computer readable media recited in claim 9 , wherein the database system account is an owner of the smart contract.

11. The one or more non-transitory computer readable media recited in claim 9 , wherein the database system account is identified in the synthetic public trust ledger party as a subordinate party.

12. The one or more non-transitory computer readable media recited in claim 9 , wherein one or more private keys are stored within the database system.

13. The one or more non-transitory computer readable media recited in claim 9 , wherein the action transfers a token from a first party to a second party.

14. The one or more non-transitory computer readable media recited in claim 9 , wherein the action mints a fungible token.

15. The one or more non-transitory computer readable media recited in claim 9 , wherein the action mints a non-fungible token.

16. The one or more non-transitory computer readable media recited in claim 9 , wherein the action updates a definition stored in the public trust ledger and reflecting the one or more synthetic public trust ledger party rules.

17. A database system configured to perform a method, the method comprising:

providing, by a database processor, computing services to a plurality of tenants of the database system via the internet;

receiving, by the database processor, from a client machine a request to execute an action related to a smart contract owned by a synthetic public trust ledger party and recorded on a public trust ledger external to the database system;

identifying, by the database processor, a database system account associated with the requested action and linked with a tenant of the plurality of tenants;

retrieving, by the database processor, from a table within the database system one or more synthetic public trust ledger party rules authorizing a plurality of database system accounts to perform a plurality of actions related to the smart contract;

determining, by the database processor, that the database system account is authorized to perform the action based on the one or more rules;

retrieving, by the database processor, one or more private keys for the synthetic public trust ledger account from the database system;

transmitting, by a ledger API, to a replica node of a public trust ledger external to the database system a ledger request to perform the action, the request authenticating the synthetic public trust ledger account to the replica node via the one or more private keys;

receiving, by the ledger API, from the replica node a ledger response indicating that the public trust ledger has been updated to reflect successful execution of the action;

updating, by the database processor, one or more records within the database system to reflect successful execution of the action; and

transmitting, by the database processor, to the client machine a response message indicating that the action has been performed.

18. The database system recited in claim 17 , wherein the database system account is an owner of the smart contract.

19. The database system recited in claim 17 , wherein the database system account is identified in the synthetic public trust ledger party as a subordinate party.

20. The database system recited in claim 17 , wherein one or more private keys are stored within the database system.