Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update ERC-3643: Move to Last Call #44

Merged
merged 9 commits into from
Nov 14, 2023
Merged

Update ERC-3643: Move to Last Call #44

Changes from 3 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
7284b9c
move to last call
Joachim-Lebrun Oct 27, 2023
8ab9d92
change eip to erc in files path
Joachim-Lebrun Oct 27, 2023
18fad82
update preamble from eip to erc
Joachim-Lebrun Oct 27, 2023
30eecaa
Update last-call-deadline
Nakasar Nov 2, 2023
24b2daf
revert to eip in preamble
Joachim-Lebrun Nov 2, 2023
c5c5ab2
Merge branch 'master' into master
Joachim-Lebrun Nov 2, 2023
cab04f1
Merge branch 'master' into master
Joachim-Lebrun Nov 6, 2023
d6a79ea
solve HTML Proofer issues
Joachim-Lebrun Nov 6, 2023
83a8501
add agent-scoped justification to rationale
Joachim-Lebrun Nov 8, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 18 additions & 17 deletions ERCS/erc-3643.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,11 @@
---
eip: 3643
erc: 3643
title: T-REX - Token for Regulated EXchanges
description: An institutional grade security token contract that provides interfaces for the management and compliant transfer of security tokens.
author: Joachim Lebrun (@Joachim-Lebrun), Tony Malghem (@TonyMalghem), Kevin Thizy (@Nakasar), Luc Falempin (@lfalempin), Adam Boudjemaa (@Aboudjem)
discussions-to: https://ethereum-magicians.org/t/eip-3643-proposition-of-the-t-rex-token-standard-for-securities/6844
status: Review
status: Last Call
last-call-deadline: 2023-11-01
type: Standards Track
category: ERC
created: 2021-07-09
Expand All @@ -30,7 +31,7 @@ The advent of blockchain technology has brought about a new era of efficiency, a

The existing Ethereum protocol, while powerful and versatile, does not fully address the unique challenges posed by security tokens. There is a need for a standard that supports compliant issuance and management of permissioned tokens, suitable for representing a wide range of asset classes, including small businesses and real estate.

The proposed [ERC-3643](./eip-3643.md) standard is motivated by this need. It aims to provide a comprehensive framework for managing the lifecycle of security tokens, from issuance to transfers between eligible investors, while enforcing compliance rules at every stage. The standard also supports additional features such as token pausing and freezing, which can be used to manage the token in response to regulatory requirements or changes in the status of the token or its holders.
The proposed [ERC-3643](./erc-3643.md) standard is motivated by this need. It aims to provide a comprehensive framework for managing the lifecycle of security tokens, from issuance to transfers between eligible investors, while enforcing compliance rules at every stage. The standard also supports additional features such as token pausing and freezing, which can be used to manage the token in response to regulatory requirements or changes in the status of the token or its holders.

Moreover, the standard is designed to work in conjunction with an on-chain Identity system, allowing for the validation of the identities and credentials of investors through signed attestations issued by trusted claim issuers. This ensures compliance with legal and regulatory requirements for the trading of security tokens.

Expand All @@ -40,7 +41,7 @@ In summary, the motivation behind the proposed standard is to bring the benefits

The proposed standard has the following requirements:

- **MUST** be [ERC-20](./eip-20.md) compatible.
- **MUST** be [ERC-20](./erc-20.md) compatible.
- **MUST** be used in combination with an onchain Identity system
- **MUST** be able to apply any rule of compliance that is required by the regulator or by the token issuer (about the factors of eligibility of an identity or about the rules of the token itself)
- **MUST** have a standard interface to pre-check if a transfer is going to pass or fail before sending it to the blockchain
Expand Down Expand Up @@ -75,7 +76,7 @@ interface IAgentRole {
}
```

The `IAgentRole` interface allows for the addition and removal of agents, as well as checking if an address is an agent. In this standard, it is the owner role, as defined by [ERC-173](./eip-173.md), that has the responsibility of appointing and removing agents. Any contract that fulfills the role of a Token contract or an Identity Registry within the context of this standard must be compatible with the `IAgentRole` interface.
The `IAgentRole` interface allows for the addition and removal of agents, as well as checking if an address is an agent. In this standard, it is the owner role, as defined by [ERC-173](./erc-173.md), that has the responsibility of appointing and removing agents. Any contract that fulfills the role of a Token contract or an Identity Registry within the context of this standard must be compatible with the `IAgentRole` interface.

### Main functions

Expand Down Expand Up @@ -111,7 +112,7 @@ The `transferFrom` function works the same way while the `mint` function and the
The `isVerified` function is called from within the transfer functions `transfer`, `transferFrom`, `mint` and
`forcedTransfer` to instruct the `Identity Registry` to check if the receiver is a valid investor, i.e. if his
wallet address is in the `Identity Registry` of the token, and if the `Identity`contract linked to his wallet
contains the claims (see [Claim Holder](../assets/eip-3643/ONCHAINID/IERC735.sol)) required in the `Claim Topics Registry` and
contains the claims (see [Claim Holder](../assets/erc-3643/ONCHAINID/IERC735.sol)) required in the `Claim Topics Registry` and
if these claims are signed by an authorized Claim Issuer as required in the `Trusted Issuers Registry`.
If all the requirements are fulfilled, the `isVerified` function returns `TRUE`, otherwise it returns `FALSE`. An
implementation of this function can be found on the T-REX repository of Tokeny.
Expand All @@ -134,7 +135,7 @@ ERC-3643 permissioned tokens build upon the standard ERC-20 structure, but with

ERC-3643 tokens implement a range of additional functions to enable the owner or their appointed agents to manage supply, transfer rules, lockups, and any other requirements in the management of a security. The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of appointing agents. Any contract that fulfills the role of a Token contract within the context of this standard must be compatible with the `IAgentRole` interface.

A detailed description of the functions can be found in the [interfaces folder](../assets/eip-3643/interfaces/IERC3643.sol).
A detailed description of the functions can be found in the [interfaces folder](../assets/erc-3643/interfaces/IERC3643.sol).

```solidity
interface IERC3643 is IERC20 {
Expand Down Expand Up @@ -197,9 +198,9 @@ The Identity Registry is linked to storage that contains a dynamic whitelist of

The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of appointing agents. Any contract that fulfills the role of an Identity Registry within the context of this standard must be compatible with the `IAgentRole` interface. The Identity Registry is managed by the agent wallet(s), meaning only the agent(s) can add or remove identities in the registry. Note that the agent role on the Identity Registry is set by the owner, therefore the owner could set themselves as the agent if they want to maintain full control. There is a specific identity registry for each security token.

A detailed description of the functions can be found in the [interfaces folder](../assets/eip-3643/interfaces/IIdentityRegistry.sol).
A detailed description of the functions can be found in the [interfaces folder](../assets/erc-3643/interfaces/IIdentityRegistry.sol).

Note that [`IClaimIssuer`](../assets/eip-3643/ONCHAINID/IClaimIssuer.sol) and [`IIdentity`](../assets/eip-3643/ONCHAINID/IIdentity.sol) are needed in this interface as they are required for the Identity eligibility checks.
Note that [`IClaimIssuer`](../assets/erc-3643/ONCHAINID/IClaimIssuer.sol) and [`IIdentity`](../assets/erc-3643/ONCHAINID/IIdentity.sol) are needed in this interface as they are required for the Identity eligibility checks.

```solidity
interface IIdentityRegistry {
Expand Down Expand Up @@ -247,7 +248,7 @@ The Identity Registry Storage stores the identity addresses of all the authorize

The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of appointing agents(in this case through the `bindIdentityRegistry` function). Any contract that fulfills the role of an Identity Registry Storage within the context of this standard must be compatible with the `IAgentRole` interface. The Identity Registry Storage is managed by the agent addresses (i.e. the bound Identity Registries), meaning only the agent(s) can add or remove identities in the registry. Note that the agent role on the Identity Registry Storage is set by the owner, therefore the owner could set themselves as the agent if they want to modify the storage manually. Otherwise it is the bound Identity Registries that are using the agent role to write in the Identity Registry Storage.

A detailed description of the functions can be found in the [interfaces folder](../assets/eip-3643/interfaces/IIdentityRegistryStorage.sol).
A detailed description of the functions can be found in the [interfaces folder](../assets/erc-3643/interfaces/IIdentityRegistryStorage.sol).

```solidity
interface IIdentityRegistryStorage {
Expand Down Expand Up @@ -286,7 +287,7 @@ This contract is triggered at every transaction by the Token and returns `TRUE`

The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of setting the Compliance parameters and binding the Compliance to a Token contract.

A detailed description of the functions can be found in the [interfaces folder](../assets/eip-3643/interfaces/ICompliance.sol).
A detailed description of the functions can be found in the [interfaces folder](../assets/erc-3643/interfaces/ICompliance.sol).

```solidity
interface ICompliance {
Expand Down Expand Up @@ -314,11 +315,11 @@ interface ICompliance {

### Trusted Issuer's Registry Interface

The Trusted Issuer's Registry stores the contract addresses ([IClaimIssuer](../assets/eip-3643/ONCHAINID/IClaimIssuer.sol)) of all the trusted claim issuers for a specific security token. The Identity contract ([IIdentity](../assets/eip-3643/ONCHAINID/IIdentity.sol)) of token owners (the investors) must have claims signed by the claim issuers stored in this smart contract in order to be able to hold the token.
The Trusted Issuer's Registry stores the contract addresses ([IClaimIssuer](../assets/erc-3643/ONCHAINID/IClaimIssuer.sol)) of all the trusted claim issuers for a specific security token. The Identity contract ([IIdentity](../assets/erc-3643/ONCHAINID/IIdentity.sol)) of token owners (the investors) must have claims signed by the claim issuers stored in this smart contract in order to be able to hold the token.

The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of managing this registry as per their requirements. This includes the ability to add, remove, and update the list of Trusted Issuers.

A detailed description of the functions can be found in the [interfaces folder](../assets/eip-3643/interfaces/ITrustedIssuersRegistry.sol).
A detailed description of the functions can be found in the [interfaces folder](../assets/erc-3643/interfaces/ITrustedIssuersRegistry.sol).

```solidity
interface ITrustedIssuersRegistry {
Expand All @@ -345,11 +346,11 @@ interface ITrustedIssuersRegistry {

### Claim Topics Registry Interface

The Claim Topics Registry stores all the trusted claim topics for the security token. The Identity contract ([IIdentity](../assets/eip-3643/ONCHAINID/IIdentity.sol)) of token owners must contain claims of the claim topics stored in this smart contract.
The Claim Topics Registry stores all the trusted claim topics for the security token. The Identity contract ([IIdentity](../assets/erc-3643/ONCHAINID/IIdentity.sol)) of token owners must contain claims of the claim topics stored in this smart contract.

The standard relies on ERC-173 to define contract ownership, with the owner having the responsibility of managing this registry as per their requirements. This includes the ability to add and remove required Claim Topics.

A detailed description of the functions can be found in the [interfaces folder](../assets/eip-3643/interfaces/IClaimTopicsRegistry.sol).
A detailed description of the functions can be found in the [interfaces folder](../assets/erc-3643/interfaces/IClaimTopicsRegistry.sol).

```solidity
interface IClaimTopicsRegistry {
Expand Down Expand Up @@ -394,8 +395,8 @@ The T-REX standard supports the implementation of additional compliance rules th
## Backwards Compatibility

T-REX tokens should be backwards compatible with ERC-20 and ERC-173
and should be able to interact with a [Claim Holder contract](../assets/eip-3643/ONCHAINID/IERC735.sol) to validate
the claims linked to an [Identity contract](../assets/eip-3643/ONCHAINID/IIdentity.sol).
and should be able to interact with a [Claim Holder contract](../assets/erc-3643/ONCHAINID/IERC735.sol) to validate
the claims linked to an [Identity contract](../assets/erc-3643/ONCHAINID/IIdentity.sol).


## Security Considerations
Expand Down