ERC-1644: Controller Token Operation Standard

[adamdossa]

---

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.
• controllerTransfer must revert
• controllerRedeem must 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
    );

}

References

• EIP 1400: Security Token Standard With Partitions
• EIP Draft

[joequant]

Hi,
I'm looking at polymath to tokenize an hedge fund, and forced transfer is a requirement. However, to make forced transfer work, I'd prefer a syntax by which the controller designates an administrative address, and can ONLY make a forced transfer between the user addresses and the administrative addresses.

The workflow for a forced transfer would be that the administrator force transfers tokens to the admin burn address, and then issues new tokens from the admin address. The reason for this is to insure that there is a audit trail for forced transfers.

[chapati23]

@adamdossa what speaks against naming this forceTransfer() instead of controllerTransfer()?

From the discussions I've been following in this space most people refer to this as "force(d) transfers" already. And the fact that you used "force" 7 times in the description to me hints at it being the clearer name.

[chapati23]

@joequant as far as i understand, every force transfer will emit an event containing all necessary data to build up an audit trail. what makes it necessary for you to have an extra-hop from investor A => back to admin => then to investor B? not sure i understand the value here, could you elaborate?

[davidbongcc]

May I know what are the byte arguments in these functions? What data should it be?

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.