ERC-2020: E-Money Standard Token

Metadata

Status: StagnantStandards Track: ERCCreated: 2019-05-10

Authors

Julio Faura (julio@adhara.io), Fernando Paris (fer@io.builders), Daniel Lehrner (daniel@io.builders)

Requires

EIP-20, EIP-1066, EIP-1996, EIP-2009, EIP-2018, EIP-2019, EIP-2021

Links

GitHub page Discussion on Ethereum Magicians

Simple Summary

The E-Money Standard Token aims to enable the issuance of regulated electronic money on blockchain networks, and its practical usage in real financial applications.

Actors

Operator

An account, which has been approved by an account to perform an action on the behalf of another account.

Abstract

Financial institutions work today with electronic systems, which hold account balances in databases on core banking systems. In order for an institution to be allowed to maintain records of client balances segregated and available for clients, such institution must be regulated under a known legal framework and must possess a license to do so. Maintaining a license under regulatory supervision entails ensuring compliance (i.e. performing KYC on all clients and ensuring good AML practices before allowing transactions) and demonstrating technical and operational solvency through periodic audits, so clients depositing funds with the institution can rest assured that their money is safe.

Motivation

There are only a number of potential regulatory license frameworks that allow institutions to issue and hold money balances for customers (be it retail corporate or institutional types). The most important and practical ones are three:

Electronic money entities: these are legally regulated vehicles that are mostly used today for cash and payments services, instead of more complex financial services. For example prepaid cards or online payment systems such as PayPal run on such schemes. In most jurisdictions, electronic money balances are required to be 100% backed by assets, which often entails holding cash on an omnibus account at a bank with 100% of the funds issued to clients in the electronic money ledger.
Banking licenses: these include commercial and investment banks, which segregate client funds using current and other type of accounts implemented on core banking systems. Banks can create money by lending to clients, so bank money can be backed by promises to pay and other illiquid assets.
Central banks: central banks hold balances for banks in RTGS systems, similar to core banking systems but with much more restricted yet critical functionality. Central banks create money by lending it to banks, which pledge their assets to central banks as a lender of last resort for an official interest rate.

Regulations for all these types of electronic money are local, i.e. only valid for each jurisdiction and not valid in others. Regulations can vary as well dramatically in different jurisdictions — for example there are places with no electronic money frameworks, on everything has to be done through banking licenses or directly with a central bank. But in all cases compliance with existing regulation needs to ensured, in particular:

Know Your Customer (KYC): the institution needs to identify the client before providing them with the possibility of depositing money or transact. In different jurisdictions and for different types of licenses there are different levels of balance and activity that can be allowed for different levels of KYC. For example, low KYC requirements with little checks or even no checks at all can usually be acceptable in many jurisdictions if cashin balances are kept low (i.e. hundreds of dollars)
Anti Money Laundering (AML): the institution needs to perform checks of parties transacting with its clients, typically checking against black lists and doing sanction screening, most notably in the context of international transactions

Beyond cash, financial instruments such as equities or bonds are also registered in electronic systems in most cases, although all these systems and the bank accounting systems are only connected through rudimentary messaging means, which leads to the need for reconciliations and manual management in many cases. Cash systems to provide settlement of transactions in the capital markets are not well-connected to the transactional systems, and often entail delays and settlement risk.

The E-Money Standard Token builds on Ethereum standards currently in use such as ERC-20, but it extends them to provide few key additional pieces of functionality, needed in the regulated financial world:

Compliance: E-Money Standard Token implements a set of methods to check in advance whether user-initiated transactions can be done from a compliance point of view. Implementations must require that these methods return a positive answer before executing the transaction.
Clearing: In addition to the standard ERC-20 transfer method, E-Money Standard Token provides a way to submit transfers that need to be cleared by the token issuing authority off-chain. These transfers are then executed in two steps:
1. transfers are ordered
2. after clearing them, transfers are executed or rejected by the operator of the token contract
Holds: token balances can be put on hold, which will make the held amount unavailable for further use until the hold is resolved (i.e. either executed or released). Holds have a payer, a payee, and a notary who is in charge of resolving the hold. Holds also implement expiration periods, after which anyone can release the hold Holds are similar to escrows in that are firm and lead to final settlement. Holds can also be used to implement collateralization.
Funding requests: users can request for a wallet to be funded by calling the smart contract and attaching a debit instruction string. The tokenizer reads this request, interprets the debit instructions, and triggers a transfer in the bank ledger to initiate the tokenization process.
Payouts: users can request payouts by calling the smart contract and attaching a payment instruction string. The (de)tokenizer reads this request, interprets the payment instructions, and triggers the transfer of funds (typically from the omnibus account) into the destination account, if possible. Note that a redemption request is a special type of payout in which the destination (bank) account for the payout is the bank account linked to the token wallet.

The E-Money Standard Token is thus different from other tokens commonly referred to as "stable coins" in that it is designed to be issued, burnt and made available to users in a compliant manner (i.e. with full KYC and AML compliance) through a licensed vehicle (an electronic money entity, a bank, or a central bank), and in that it provides the additional functionality described above, so it can be used by other smart contracts implementing more complex financial applications such as interbank payments, supply chain finance instruments, or the creation of E-Money Standard Token denominated bonds and equities with automatic delivery-vs-payment.

Specification

Mandatory checks

The checks must be verified in their corresponding actions. The action must only be successful if the check return an Allowed status code. In any other case the functions must revert.

Status codes

If an action is allowed 0x11 (Allowed), or an issuer-specific code with equivalent but more precise meaning must be returned. If the action is not allowed the status must be 0x10 (Disallowed), or an issuer-specific code with equivalent but more precise meaning.

Functions

currency

Returns the currency that backs the token. The value must be a code defined in ISO 4217.

Parameter	Description
-	-

version

Returns the current version of the smart contract. The format of the version is up to the implementer of the EIP.

Parameter	Description
-	-

availableFunds

Returns the total net funds of an account. Taking into consideration the outright balance and the held balances.

Parameter	Description
account	The account which available funds should be returned

checkTransferAllowed

Checks if the transfer or transferFrom function is allowed to be executed with the given parameters.

Parameter	Description
from	The address of the payer, from whom the tokens are to be taken if executed
to	The address of the payee, to whom the tokens are to be transferred if executed
value	The amount to be transferred

checkApproveAllowed

Checks if the approve function is allowed to be executed with the given parameters.

Parameter	Description
from	The address of the payer, from whom the tokens are to be taken if executed
spender	The address of the spender, which potentially can initiate transfers on behalf of `from`
value	The maximum amount to be transferred

checkHoldAllowed

Checks if the hold function is allowed to be executed with the given parameters.

Parameter	Description
from	The address of the payer, from whom the tokens are to be taken if executed
to	The address of the payee, to whom the tokens are to be transferred if executed
notary	The address of the notary who is going to determine whether the hold is to be executed or released
value	The amount to be transferred. Must be less or equal than the balance of the payer

checkAuthorizeHoldOperatorAllowed

Checks if the checkAuthorizeHoldOperatorAllowed function is allowed to be executed with the given parameters.

Parameter	Description
operator	The address to be approved as operator of clearable transfers
from	The address on which behalf holds could potentially be issued

checkOrderTransferAllowed

Checks if the orderTransfer function is allowed to be executed with the given parameters.

Parameter	Description
from	The address of the payer, from whom the tokens are to be taken if executed
to	The address of the payee, to whom the tokens are to be paid if executed
value	The amount to be transferred. Must be less or equal than the balance of the payer

checkAuthorizeClearableTransferOperatorAllowed

Checks if the authorizeClearableTransferOperator function is allowed to be executed with the given parameters.

Parameter	Description
operator	The address to be approved as operator of clearable transfers
from	The address on which behalf clearable transfers could potentially be ordered

checkOrderFundAllowed

Checks if the orderFund function is allowed to be executed with the given parameters.

Parameter	Description
to	The address to which the tokens are to be given if executed
operator	The address of the requester, which initiates the funding order
value	The amount to be funded

checkAuthorizeFundOperatorAllowed

Checks if the authorizeFundOperator function is allowed to be executed with the given parameters.

Parameter	Description
operator	The address to be approved as operator of ordering funding
to	The address which the tokens are to be given if executed

checkOrderPayoutAllowed

Checks if the orderPayout function is allowed to be executed with the given parameters.

Parameter	Description
from	The address from whom the tokens are to be taken if executed
operator	The address of the requester, which initiates the payout request
value	The amount to be paid out

checkAuthorizePayoutOperatorAllowed

Checks if the authorizePayoutOperator function is allowed to be executed with the given parameters.

Parameter	Description
operator	The address to be approved as operator of ordering payouts
from	The address from which the tokens are to be taken if executed

Rationale

This EIP unifies ERC-1996, ERC-2018, ERC-2019 and ERC-2021 and adds the checks for the compliance on top of it. By this way the separate EIPs are otherwise independent of each other, and the E-Money Standard Token offers a solution for all necessary functionality of regulated electronic money.

While not requiring it, the naming of the check functions was adopted from ERC-1462.

Backwards Compatibility

This EIP is fully backwards compatible as its implementation extends the functionality of ERC-1996, ERC-2018, ERC-2019, ERC-2021 and ERC-1066.

Implementation

The GitHub repository IoBuilders/em-token contains the work in progress implementation.

Contributors

This proposal has been collaboratively implemented by adhara.io and io.builders.

Copyright