PrivateERCToken
The functions supporting privacy tokens are defined in the interface IPrivateERCToken.
Employing the account balance model within our private token smart contracts, transaction execution necessitating balance verification triggers a reservation mechanism. This involves partitioning a specific quantity, termed "private amount" in the context of privacy support, from an address's balance.
To facilitate the development and administration of both standard and privacy-centric tokens, we have provisioned the foundational smart contract, "PrivateERCToken," which implements this interface. This base contract is architected for extensibility, allowing clients to implement bespoke token smart contract logic.
PrivateERCToken inherently supports established Ethereum token standards, notably ERC20 and ERC1155, while concurrently enabling the issuance and governance of private amounts with augmented confidentiality attributes. The contract encompasses a comprehensive set of intrinsic functions for fundamental token operations, including minting, splitting, transferring, merging, and burning.
By leveraging privateTokenScBase, customers can ensure their tokens are interoperable, secure, and ready for advanced transaction models such as Delivery versus Payment (DvP), all while maintaining compliance with privacy and security requirements.
Key Capabilities:
- Support for both public (Ethereum-standard) and private tokens
- Secure minting and burning operations
- Token splitting for reservation
- Balance aggregation (merging) to optimize ledger storage
- Cross-standard balance conversion (Erc20/Erc1155 balance to private token)
Token Lifecycle
Token origination occurs via a Mint operation, generating a new token and depositing it into the incoming transfer list of an address. Tokens within an address's incoming transfer queue can be aggregated into the address's consolidated balance through a Merge operation.
A Split operation allows for the disaggregation of an address's consolidated balance into multiple individual token units, which are then placed in the address's outgoing transfer queue. A token Transfer operation moves the token from the sender's outgoing transfer storage to the recipient's incoming transfer queue.
Token destruction is achieved through a Burn operation, where a token is moved from an address's outgoing transfer list and permanently removed from the system. The incoming and outgoing transfer queues/list/storage/box serve as intermediary stages for token receipt and dispatch, respectively, before consolidation into or dispersal from the address's central balance.
The provided diagram below illustrates a token lifecycle. The example comprises addresses (Address A, Address B), each with an incoming transfer queue ("in"), an outgoing transfer queue ("out"), and a consolidated token balance ("Consolidated Balance: Balance").
Token Storage Structure
The privacy enabled ERC-20 Smart Contract has an additional storage structure composed as a map from addresses to a structure that accommodates a consolidated balance field and 3 lists: in (inbox), out (outbox) and apv (approved). The inbox list stores all the incoming transfer amounts while waiting for the merge step of the privateReserveAmount function. The outbox list stores all the outgoing transfer amounts while waiting for the correspondent privateTransfer function call. The approved list stores the allowances amounts while waiting for the corresponding privateTransferFrom, or the respective rollBackBalance function call. Figure 1 illustrates this concept.
