A Purpose Bound Money (PBM) token is a wrapper around an ERC-1155 token that can be used for a limited activity. This proposal outlines a smart contract interface that builds upon the ERC-1155 standard to implement the purpose bound money (PBM) concept:
In this EIP, we propose a modular structure consisting of a sovToken compatible with ERC-20 as the digital money, an ERC-1155 compatible smart contract as the PBM wrapper, a compliance guard smart contract as a component of the PBM Wrapper logic, and a PBM token manager smart contract to manage token registration and retrieval.
Purpose Bound Money (PBM) enables digital currencies to carry conditions on how they can be spent, making them especially useful in real-world scenarios such as:
This proposal intends to forestall technology fragmentation and consequently a lack of interoperability. By making the PBM specification open, it gives new participants easy and free access to the pre-existing market standards, enabling interoperability across different platforms, wallets, payment systems and rails. This would lower cost of entry for new participants, foster a vibrant payment landscape and prevent the development of walled gardens and monopolies, ultimately leading to more efficient, affordable services and better user experiences.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
sovToken - an ERC-20 or ERC-20 compatible digital currency (e.g. ERC-777, ERC-1363) serving as the store of value token (i.e. collateral backing the PBM Token).
PBM Wrapper - an ERC-1155 compliant smart contract, which wraps the sovToken by specifying one or more conditions that have to be met (referred to as PBM business logic in subsequent section of this proposal). The PBM wrapper can be designed to be modular in nature, with core, plug-ins and hooks components (see section on PBM Architecture for elaboration). The PBM wrapper smart contract, together with adopted hooks smart contracts verifies that condition(s) has/have been met before unwrapping the underlying sovToken.
PBM Token - the sovToken and its PBM wrapper are collectively referred to as a PBM Token. PBM Tokens are represented as ERC-1155 tokens.
PBM Creator defines the conditions of the PBM Wrapper to create PBM Tokens.
Merchant / Redeemer - In the context of this proposal, a Merchant or a Redeemer is broadly defined as the ultimate recipient, or endpoint, for PBM tokens, to which these tokens are intrinsically directed or purpose-bound to. The identity of merchant/redeemer will be one of the validations performed by the compliance guard, which may be implemented as part of the PBM Wrapper smart contract or as a standalone compliance guard contract registered as a PBM hook.
PBM SHALL adhere to the definition of "wrap" or "wrapping" to mean binding a token in accordance with PBM business logic throughout its lifecycle.
PBM SHALL adhere to the definition of "unwrap" or "unwrapping" to mean the release of a token in accordance with the PBM business logic during its lifecycle stage.
A valid PBM Token MUST consist of an underlying sovToken and a PBM Wrapper.
The sovToken can be wrapped either upon the creation of the PBM Token or at a later date.
A sovToken can be implemented as any widely accepted ERC-20 compatible token, such as ERC-20, ERC-777, or ERC-1363.
PBM Wrapper MUST provide a mechanism for all transacting parties to verify that all necessary condition(s) have been met before allowing the PBM Token to be unwrapped. Refer to Auditability section for elaborations. The necessary conditions can be implemented within the PBM wrapper, or in a separate PBM hook(s) smart contract(s).
PBM Wrapper MUST ensure the destination address for unwrapped sovToken is in a whitelist of Merchant/Redeemer addresses and not in a blacklist of banned addresses prior to unwrapping the underlying sovToken.
The PBM Token MUST be burnt upon being fully unwrapped and used.
A PBM Token SHOULD have an expiry time that is decided by the PBM Creator.
This proposal defines a base specification of what a PBM should entail. Extensions to this base specification can be implemented as separate specifications.
In this EIP, we propose a modular PBM architecture that has three distinct components (the core, the plugins and the hooks):
For example, a PBM creator may want to ensure that only 50% of PBM Series A can be spent in supermarkets, while there are no restrictions on the proportion of PBM Series B that can be spent in supermarkets. The creator can implement a plugin smart contract to keep track of supermarket spending by PBM users and a hook to validate that less than 50% of the PBM Series A issued to a user is spent in a supermarket. This approach allows the same generic PBM wrapper and sovToken to be used for both PBM Series A and B. In addition, PBM Series A will register the plugin module and hook module for additional data tracking and validations.
PBM Wrapper SHOULD provide the public easily accessible mechanism(s) to verify the smart contract logic for unwrapping a PBM. Such mechanisms could be leveraged by automated validation or asynchronous user verifications from transacting parties and/or whitelisted third parties attestations.
As the fulfilment of PBM conditions is likely to be subjected to audits to ensure trust amongst all transacting parties, the following evidence shall be documented to support audits:
A PBM Wrapper SHOULD be able to wrap multiple types of compatible sovTokens (e.g. the same PBM Wrapper should be able to wrap USDC and XSGD). sovTokens wrapped by the same PBM wrapper may or may not be fungible to one another. The standard does NOT mandate how an implementation must do this.
The ERC-1155 Multi Token Standard enables each token ID to correspond to a unique, configurable token type. All essential details facilitating the business or display logic for a PBM MUST be defined for each token type. The mandatory fields for this purpose are outlined in the struct PBMToken (below). Future proposals may define additional, optional state variables as needed. Once a token detail has been defined, it MUST be immutable.
Example of token details:
An implementer of the standard can enhance their PBM tokens with additional functionality by implementing the IPBMRC1_TokenManagerExt interface. This extension provides optional properties that can be used to support a variety of use cases beyond the core requirements.
An implementer has the option to define all token types upon PBM contract deployment. If needed, they can also expose an external function to create new PBM tokens at a later time.
All token types created SHOULD emit a NewPBMTypeCreated event.
Implementors of the standard MUST define a method to retrieve a PBM token detail
A compliance guard should have logic to store and retrieve whitelisted merchants/redeemers and blacklisted addresses to fulfill the basic premise of a PBM. Additional logic can be added to fulfill other compliance goals.
This interface contains the essential functions required to implement a pre-loaded PBM.
Smart contracts MUST implement all of the functions in the PBMRC1_TokenReceiver interface to subscribe to PBM unwrap callbacks.
The Non Preloaded PBM extension is OPTIONAL for compliant smart contracts. This allows contracts to bind an underlying sovToken to the PBM at a later date instead of during a minting process.
Compliant contract MUST implement the following interface:
As PBM is envisioned to have functionality of money, it has to be a fungible token with stable value. Currently, the major stablecoins in the market are mainly based on the ERC-20 interface. ERC-20 or ERC-20 compatible tokens are the most widely supported by existing wallets, defi apps, and used also by protocol design such as ERC-4337 and more importantly they are the de facto standard for fungible tokens.
With regards to ERC-721 and ERC-1155 compatible tokens:
This paper extends the ERC-1155 standards in order to enable easy adoption by existing wallet providers. Currently, most wallet providers are able to support and display ERC-20, ERC-1155 and ERC-721 standards. An implementation which doesn't extend these standards will require the wallet provider to build a custom user interface and interfacing logic which increases the implementation cost and lengthen the time-to-market.
The core aim of our proposal is to standardize the implementation of PBM. Hence, we have surveyed existing interface standards and decided to build upon ERC-1155 standard for the PBM tokens for the following reasons:
Why do we need a whitelist?
Why do we need a blacklist?
Why we can't have either a whitelist or a blacklist?
Why is there a need for destination?
safeTransfer function.Each ERC-1155 PBM Token would map to an underlying PBMToken data structure that implementers are free to customize in accordance to the business logic.
By mapping the underlying ERC-1155 token model with an additional data structure, implementers gain flexibility in the management of multiple token types within the same smart contract with multiple conditional unwrapping logic attached to each token type, reducing gas costs as there is no need to deploy multiple smart contracts for each token type.
To keep it simple, this standard intentionally omits functions or events that doesn't add to definition and concept of a PBM.
This EIP makes no assumptions about access control or the conditions under which a function can be executed. It is the responsibility of the PBM creator to determine the various roles involved in each specific PBM business flow.
The proposed PBM Architecture intentionally modular to enable greater customisability and reusability of smart contracts.
Metadata associated to the PBM standard is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface, e.g. ERC721Metadata from ERC-721. Refer to Opensea's metadata-standards for an implementation example.
To allow for future extensibility, it is RECOMMENDED that developers read and adopt the specifications for building general extensibility for method behaviours (ERC-5750).
This interface is designed to be compatible with ERC-1155.
Reference implementations can be found in README.md.
Malicious users may attempt to:
For consistency, when the contract is suspended or a user's token transfer is restricted due to suspected fraudulent activity or erroneous transfers, corresponding restrictions MUST be applied to the user's unwrap requests for the PBM Token.
Security audits and tests should be performed to verify that unwrap logic behaves as expected or if any complex business logic is being implemented that involves calling an external smart contract to prevent re-entrancy attacks and other forms of call chain attacks.
This EIP relies on the secure and accurate bookkeeping behavior of the token implementation.
Contracts adhering to this standard should closely monitor balance changes for each user during token consumption or minting.
The PBM Wrapper must be meticulously designed to ensure effective control over the permission to mint new tokens. Failure to secure the minting permission can lead to fraudulent issuance and unauthorized inflation of the total token supply.
The mapping of each PBM Token to the corresponding amount of underlying sovToken held by the smart contract requires careful accounting and auditing.
The access control over permission to burn tokens should be carefully designed. Typically, only the following two roles are entitled to burn a token:
Nevertheless, we do recognize there are potentially other use cases where a third type of role may be entitled to burning. Implementors should be cautious when designing access control over burning of PBM Tokens.
It is recommended to adopt a sovToken standard that is compatible with ERC-20. Examples of such compatible tokens include those implementing ERC-777 or ERC-1363. However, ERC-20 remains the most widely accepted due to its simplicity and there is a high degree of confidence in its security.
Copyright and related rights waived via CC0.