Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
ERC860: Custodian-Client Contract Standard #860
A standard interface of custodian smart contracts that allows on-chain creating and tracking of client smart contract instances. A two-level smart contract hierarchy is therefore constructed. A typical use case is valuable asset management, ranging from digital coupons and concert tickets to high-value commodities such as diamond grading certificates.
The paper of this standard specification has been recognized and accepted by the 16th ACM International Conference on Mobile Systems, Applications, and Services - Cryptocurrencies and Blockchains for Distributed Systems. (Munich, Germany)
This standard allows for the implementation of a standard API for Custodian-Client Contracts (henceforth referred to as "CCCs") within smart contracts. This standard also proposes a two-level hierarchical architecture that is composed of two types of smart contracts: custodian and client. A custodian contract can deploy on-demand client contract, access their data and call their methods to perform specific updates. Furthermore, a framework is developed to allow client contracts to share common variables among all or partial group of the contracts, which may only be mutated by its creator, custodian contracts. Specifically, this standard provides basic functionality to establish associations between a custodian smart contract and multiple client smart contracts.
Compared to ERC721, this standard creates the new entity as a smart contract instead of an instance of Struct in view of the following reasons:
To summarize, ERC860 can be viewed as an extended standard from ERC721 with a different implementation that preserves the specialty and independence of each token instance, improves the fraud resistance, and provides flexible compatibility with other standards in the meantime.
A representative example of smart contracts that interact in a hierarchical way is the one of a ticket selling contract. Each ticket is created automatically by the contract of the higher level. As shown in the following figure, whenever a customer buys a ticket, the ticket seller creates a new ticket and gives it to the customer (i.e., deploys a new smart contract and assigns as owner the id of the customer). As whom to distribute tickets to its customers, the ticket seller performs the role of a Custodian smart contract. Client smart contract will be created and owned by the customer once the ticket is purchased. Customers are allowed to exchange or sell tickets to others by transferring the ownership of his/her Client smart contract. The ticket seller is able to retrieve the updated information when querying since the Client contracts can be restored by the deployment address which the Custodian smart contract keeps track of. If as time passes by, the ticket seller wishes to update the shared random seed to boost security, the Custodian smart contract will call the Client contracts again by its deployed address and perform the update accordingly.
A phonebook-like mapping from a given client ID to the corresponding client contract address.
Create a client with a generated ID (generation mechanism specified below) and return the ID.
Generate an ID based on the created client contract address.
MUST be triggered when
Smart contracts associated with ownership that can be obtained and transferred. Here is a concrete example of Digital Coupon Smart Contract.
A sample implementation of Digital Coupon Application.
Copyright and related rights waived via CC0.