Description
eip: ERC-1644
title: Controller Token Operation Standard (part of the ERC-1400 Security Token Standards)
author: Adam Dossa (@adamdossa), Pablo Ruiz (@pabloruiz55), Fabian Vogelsteller (@frozeman), Stephane Gosselin (@thegostep)
discussions-to: #1411
status: Draft
type: Standards Track
category: ERC
created: 2018-09-09
require: None
Simple Summary
This standard sits under the ERC-1400 (#1411) umbrella set of standards related to security tokens.
Provides a standard to support controller operations (aka forced transfers) on tokens.
Abstract
Allows a token to transparently declare whether or not a controller can unilaterally transfer tokens between addresses.
Motivation
Accelerate the issuance and management of securities on the Ethereum blockchain by specifying a set of standard interfaces through which security tokens can be operated on and interrogated by all relevant parties.
Since security tokens are subject to regulatory and legal oversight (the details of which will vary depending on jurisdiction, regulatory framework and underlying asset) in many instances the issuer (or a party delegated to by the issuer acting as a controller, e.g. a regulator or transfer agent) will need to retain the ability to force transfer tokens between addresses.
These controller transfers should be transparent (emit events that flag this as a forced transfer) and the token contract itself should be explicit as to whether or not this is possible.
Examples of where this may be needed is to reverse fraudulent transactions, resolve lost private keys and responding to a court order.
Requirements
See ERC-1400 (#1411) for a full set of requirements across the library of standards.
The following requirements have been compiled following discussions with parties across the Security Token ecosystem.
- MUST be able to perform forced transfer for legal action or fund recovery.
Rationale
Given the conflict between this functionality and the decentralised nature of Ethereum, making such actions, and the ability to execute these transactions, as transparent as possible allows different use-cases to comply with the standard.
Rationale
A token representing ownership in a security may require authorised operators to have additional controls over the tokens.
This includes the ability to issue additional supply, as well as make forced transfers of tokens. The standard allows these controls to be managed and also critically ensures their transparency. If an issuer requires the ability to issue additional tokens, or make controller transfers (forced transfers) then these rights can be transparently assessed rather than being implemented in a bespoke or obfuscated manner.
Specification
In some jurisdictions the issuer (or an entity delegated to by the issuer) may need to retain the ability to force transfer tokens. This could be to address a legal dispute or court order, or to remedy an investor losing access to their private keys.
controllerTransfer
This function allows an authorised address to transfer tokens between any two token holders. The transfer must still respect the balances of the token holders (so the transfer must be for at most balanceOf(_from) tokens) and potentially also need to respect other transfer restrictions.
controllerTransfer MUST emit a ControllerTransfer event.
function controllerTransfer(address _from, address _to, uint256 _value, bytes _data, bytes _operatorData) external;controllerRedeem
This function allows an authorised address to redeem tokens for any token holder. The redemption must still respect the balances of the token holder (so the redemption must be for at most balanceOf(_tokenHolder) tokens) and potentially also need to respect other transfer restrictions.
controllerTransfer MUST emit a ControllerRedemption event.
function controllerRedeem(address _tokenHolder, uint256 _value, bytes _data, bytes _operatorData) external;isControllable
In order to provide transparency over whether controllerTransfer / controllerRedeem are useable, the function isControllable can be used.
If a token returns FALSE for isControllable() then it MUST:
- always return FALSE in the future.
controllerTransfermust revertcontrollerRedeemmust revert
In other words, if an issuer sets isControllable to return FALSE, then there can be no further controller transactions for this token contract.
function isControllable() external view returns (bool);Interface
/// @title IERC1644 Controller Token Operation (part of the ERC1400 Security Token Standards)
/// @dev See https://github.com/SecurityTokenStandard/EIP-Spec
interface IERC1644 is IERC20 {
// Controller Operation
function isControllable() external view returns (bool);
function controllerTransfer(address _from, address _to, uint256 _value, bytes _data, bytes _operatorData) external;
function controllerRedeem(address _tokenHolder, uint256 _value, bytes _data, bytes _operatorData) external;
// Controller Events
event ControllerTransfer(
address _controller,
address indexed _from,
address indexed _to,
uint256 _value,
bytes _data,
bytes _operatorData
);
event ControllerRedemption(
address _controller,
address indexed _tokenHolder,
uint256 _value,
bytes _data,
bytes _operatorData
);
}