ERC-7291: Purpose bound money

An interface extending ERC-1155 to implement purpose-bound money, a hybrid form of programmable payment and money.

Metadata
Status: DraftStandards Track: ERCCreated: 2023-06-24
Authors
Orchid-Dev (@proj-orchid-straitsx), Victor Liew (@alcedo), Wong Tse Jian (@wongtsejian), Jacob Shan (@Jacobshan429), Chin Sin Ong (@chinsinong)
Requires
EIP-165, EIP-173, EIP-1155
Links
GitHub pageDiscussion on Ethereum Magicians

Abstract

This proposal outlines a smart contract interface that builds upon the ERC-1155 standard to implement the purpose bound money (PBM) concept:

  • PBMs is comprised of a PBM wrapper and a digital money token that it wraps. A digital money token (e.g. stablecoins, central bank digital currency, tokenised bank deposits etc) serves as as a store of value (abbreviated as "sov"). Thus, a digital money token (also referred to as "sovToken") SHOULD be:
    • a good store of value;
    • a suitable unit of account; and
    • a medium of exchange.
  • PBMs are bearer instruments, with self-contained programming logic, and can be transferred between two parties without involving intermediaries. It combines the concept of:
    • programmable payment - automatic execution of payments once a pre-defined set of conditions are met; and
    • programmable money - the possibility of embedding rules within the medium of exchange itself that defines or constraints its usage.
  • Once the conditions are met, sovToken is released, and it becomes unbounded once again. A PBM can be taught of as a digital cash voucher, because it places constraint on how a payer can use the PBM but does not imposes any constraints on the merchant/redeemer because the PBM unwraps and releases the underlying digital money upon payment to the merchant/redeemer. This is akin to a physical cash voucher, where the payer is restricted to purchases from the merchants specified by the issuer but the merchants accepting the vouchers can exchange the physical vouchers with the issuer for fiat money.

In this EIP, we propose a modular structure consisting of an ERC-20 compatible sovToken as the digital money, an ERC-1155 compatible smart contract as the PBM wrapper, an address list smart contract as the PBM logic and a PBM token manager smart contract to manage token registration and retrieval.

Motivation

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.

Specification

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.

Definitions

  • 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 a ERC-1155 token.

  • PBM Creator defines the conditions of the PBM Wrapper to create PBM Tokens.

  • PBM Wallet - cryptographic wallets which can either be an EOA (Externally Owned Account) that is controlled by a private key, or a smart contract wallet.

  • 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 specify in the PBM Address List (which can be part of the PBM Wrapper smart contract or a standalone PBM Address List smart contract that is registered as a PBM hook).

Overview

  • PBM SHALL adhere to the definition of “wrap” or “wrapping” to mean bounding a token in accordance with PBM business logic during its lifecycle stage.

  • 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 consists of an underlying sovToken and the 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.

    • For cases where an expiry time is not needed, the expiry time SHOULD be set to infinity.

  • This proposal defines a base specification of what a PBM should entail. Extensions to this base specification can be implemented as separate specifications.

PBM Architecture

In this EIP, we propose a modular PBM architecture that has three distinct components (the core, the plugins and the hooks):

  • The core components contains basic functionalities and validation checks that all PBMs should have. Core components includes sovToken and PBM wrapper containing the core logic (e.g. logic to whitelist the merchant/redeemer address, logic to unwrap upon transfer to a whitelisted address, logic for minting and burning the PBM) and a token manager which allows for token registration, retrieval. In addition, the PBM wrapper MAY include logic to interface with plugins and hooks.
  • The plugin components implement additional functionality that only specific PBMs may require (e.g. logic to call external application programming interfaces to verify specific PBM condition was met, logic to track PBM usage patterns).
  • The hook components implement additional validation checks that some PBMs may need (e.g. checks for expiration, daily spending limit, goods & services limit etc).

For example, a PBM creator may want to ensure only 50% of PBM Series A can be spent in supermarkets, while there are no restriction on proportion of PBM Series B that can be spent in supermarkets. He can implement a plugin smart contract to keep track of supermarket spendings by PBM users. He will also implement a hook to validate that less than 50% of the PBM Series A issued a user is spent in a supermarket. This allows him to use the same generic PBM wrapper and sovToken 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.

Auditability

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:

  • The interface/events emitted SHOULD allow a fine-grained recreation of the transaction history, token types and token balances
  • The source code SHOULD be verified and formally published on a blockchain explorer.

Fungibility

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.

PBM token details

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 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




PBM Address List


A targeted address list for PBM unwrapping must be specified. This list can be supplied either
through the initialization function as part of a composite contract that contains various business logic elements,
or it can be coded directly as a state variable within a PBM smart contract.




PBMRC1 - Base Interface


This interface contains the essential functions required to implement a pre-loaded PBM.




Extensions


PBMRC1 - Token Receiver


Smart contracts MUST implement all of the functions in the PBMRC1_TokenReceiver interface to subscribe to PBM unwrap callbacks.




PBMRC2 - Non preloaded PBM Interface


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:




Rationale


Why sovToken MUST be ERC-20 compatible?


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:


    

  • ERC-721 is not suitable given that it is a standard for non-fungible tokens, which cannot fulfill the functions of money.
    • 

  • While ERC-1155 tokens could be used for fungible tokens, we decided not to include it because there is a lack of ERC-1155 stablecoins in the market. Requiring the PBM interface to support both ERC-20 compatible and ERC-1155 compatible sovToken would complicate PBM interface without adding much practical utility. Furthermore, the base ERC-1155 does not support decimals, but this is not a dealbreaker as there can be workarounds. However, should there be changes in the stablecoin market in future, a revision can be considered.
    • 



Why PBM Wapper MUST be ERC-1155 compatible?


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:


    

  • ERC-1155 allows a single contract to support multiple tokens. This is very useful for the PBM use cases as a single contract can support issuance of tokens with different denominations, expiry dates, business logics.
    • 

  • ERC-1155 also has batch transfer support, which is absent in ERC-20, which could lead to gas savings when tokens have to be airdropped to a large number of recipients.
    • 

  • ERC-1155 is able to support semi-fungible tokens which could be very useful for PBM use cases as a PBM can be converted into a collectible after its expiry.
    • 

  • ERC-1155 allows for a visualisation of a PBM token on the UI of a wallet issuer.
    • 



Why PBM 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?


Why we need a whitelist?


    

  • The whitelist is a compulsory requirement because a PBM is purpose-bound, i.e. it should be unwrapped only if all conditions are fulfilled and it is transferred to someone in the predefined whitelist.
    • 

  • In some implementations, developers can define that a whitelisted address is something that is dynamically determined at run time as well, such as presence of an NFT in a wallet address, or relying on an oracle etc.
    • 



Why we need a blacklist?


    

  • The blacklist is a compulsory requirement to ensure that accounts which were banned for various reasons (e.g. address owner has re-registered a new account, address owner suspended/withdrawn/expelled due to complaints or law enforcement reason etc).
    • 



Why we can’t have either a whitelist or a blacklist?


    

  • While the same effect can be obtained by only having a whitelist, repeatedly redeploying the whitelist to the blockchain to ban one person is not gas efficient.
    • 

  • Using a blacklist to implement purpose-bound money is not practical as you would need to have a list of all addresses to be excluded and update it whenever a new account is created.
    • 



Why is there a need for destination?


    

  • This actually forms the core of what we are trying to propose - a PBM can only be unwrapped when it is transferred to pre-approved destinations.
    • 

  • PBM can be transferred freely, but the target allowed to unwrap the PBM and take delivery of the underlying sovToken must be limited to differentiate it from plain vanilla stablecoins that are wrapped by smart contracts
    • 



What does business logic encompasses?


    

  • In general, business logic can be divided into core, plugin and hook logic:

      

    • Core logic contains essential functionalities and validation checks and should be included in the PBM Wrapper contract.
      • 

    • Plugin and hook logic can be contained in standalone smart contract modules and are registered by the PBM Wrapper contract. Plugin logic extends the core logic by adding functionality, e.g. custom data collection, additional administrative functions etc.
      • 

    • Hook logic implements additional validation checks which are only applicable for a subset of PBMs.
      • 

    

    • 

  • “PBM business logic” can contain access control logic, PBM unwrapping logic, API logic to integrate with non-blockchain IT systems.
    • 

  • As PBM can be used for a wide variety of use cases, ranging from government disbursement tokens, shopping vouchers, prepaid tokens, rewards points tokens, purpose bound donation token, school allowance token etc, with each use cases having a separate business logic, it was intentionally left undefined so that implementation authors can have maximum flexibility.
    • 



Why was a push transaction model chosen?


    

  • This standard sticks to the push transaction model where the transfer of PBM is initiated on the sender's side. Modern wallets can support the required PBM logic by embedding the unwrapping logic within the ERC-1155 safeTransfer function.
    • 



Customisability


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, it allows for the flexibility in the management of multiple token types within the same smart contract with multiple conditional unwrapping logic attached to each token type which reduces the gas costs as there is no need to deploy multiple smart contracts for each token types.


    

  1. 

    To keep it simple, this standard intentionally omits functions or events that doesn't add to definition and concept of a PBM.
    

    2. 

  2. 

    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.
    

    3. 

  3. 

    The proposed PBM Architecture intentionally modular to enable greater customisability and reusability of smart contracts.
    

    4. 

  4. 

    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.
    

    5. 

  5. 

    To allow for future extensibility, it is RECOMMENDED that developers read and adopt the specifications for building general extensibility for method behaviours (ERC-5750).
    

    6. 



Backwards Compatibility


This interface is designed to be compatible with ERC-1155.


Reference Implementation


Reference implementations can be found in README.md.


Security Considerations


    

  • 

    Everything used in a smart contract is publicly visible, even local variables and state variables marked private.
    

    • 

  • 

    Due to gas limit, loops that do not have a fixed number of iterations have to be used cautiously.
    

    • 

  • 

    Never use tx.origin to check for authorization. msg.sender should be used to check for authorization.
    

    • 

  • 

    If library code is used as part of a delegatecall, make sure library code is stateless to prevent malicious actors from changing state in your contract via delegatecall.
    

    • 

  • 

    Malicious actors may try to front run transactions. As transactions take some time before they are mined, an attacker can watch the transaction pool and send a transaction, have it included in a block before the original transaction. This mechanism can be abused to re-order transactions to the attacker's advantage. A commitment scheme can be used to prevent front running.
    

    • 

  • 

    Don't use block.timestamp for a source of entropy and random number.
    

    • 

  • 

    Signing messages off-chain and having a contract that requires that signature before executing a function is a useful technique. However, the same signature can be exploited by malicious actors to execute a function multiple times. This can be harmful if the signer's intention was to approve a transaction once. To prevent signature replay, messages should be signed with nonce and address of the contract.
    

    • 

  • 

    Malicious users may attempt to:
    

      

    • Double spend through reentrancy.
      • 

    • clone existing PBM Tokens to perform double-spending;
      • 

    • create invalid PBM Token with no underlying sovToken; or
      • 

    • falsifying the face value of PBM token through wrapping of fraudulent/invalid/worthless sovTokens.
      • 

    

    • 

  • 

    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:
      

        

      • Role 1. Prior to a PBM expiry, only whitelisted merchants/redeemers with non-blacklisted wallet addresses are allowed to unwrap and burn tokens that they holds.
        • 

      • Role 2. After a PBM has expired:

          

        • whitelisted merchants/redeemers with non-blacklisted wallet addresses are allowed to unwrap and burn tokens that they hold; and
          • 

        • PBM owners are allowed to burn unused PBM Tokens remaining in the hands of non-whitelisted merchants/redeemers to retrieve underlying sovTokens.
          • 

        

        • 

      

      • 

    • 

      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 token standard that is compatible with ERC-20. Examples of such compatible tokens includes tokens implementing ERC-777 or ERC-1363. However, ERC-20 remains the most widely accepted because of its simplicity and there is a high degree of confidence in its security.
    

    • 



Copyright


Copyright and related rights waived via CC0.