はじめに

初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

代表的なゲームはクリプトスペルズというブロックチェーンゲームです。

今回は、機関投資家向けのセキュリティ・トークン・コントラクトで、セキュリティ・トークンの管理とコンプライアンスに基づくtransferのためのインターフェースの仕組みを提案している規格であるERC3643についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

他にも様々なERCについてまとめています。

概要

T-REXトークンは、デジタル資産のセキュリティと取引を保証するための新しい標準です。
この標準は、特に金融機関や大きな投資家向けに設計されており、セキュリティトークン（つまり、何らかの資産や権利を表すデジタルトークン）の安全な取引を可能にします。

トークン

これは、実際の資産や権利をデジタル化したものです。
例えば、不動産や株式などがトークン化されることがあります。
トークンコントラクトは、これらのトークンを作成し、送信し、取引する機能を提供します。

アイデンティティレジストリ

投資家やユーザーの身元情報を管理するためのシステムです。
このシステムは、各ユーザーがトークンの取引を行う資格があるかどうかを確認するのに使われます。

アイデンティティレジストリストレージ

アイデンティティレジストリのデータを安全に保管する場所です。
ここには、ユーザーの身元情報が保存されます。

コンプライアンス

トークン取引が法律や規制に従って行われているかを監視し、不正な取引を防ぐシステムです。
このコントラクトは、取引が許可される前にさまざまなチェックを行います。

信頼される発行者レジストリ

トークンを発行する権限を持つ、信頼できる組織や個人のリストを管理します。
これにより、質の高いトークンだけが市場に流通することを保証します。

クレームトピックスレジストリ

ユーザーの身元や資格に関する情報（クレーム）の種類を管理するシステムです。
これは、ユーザーがトークンを取引するための資格があることを確認するのに使われます。

T-REXトークン標準は、セキュリティトークンの取引を安全かつ効率的に行うための一連のルールとツールを提供します。
これにより、大規模な投資家も規制を守りながらデジタル資産市場に参入できるようになります。

動機

ブロックチェーン技術は、ピアツーピアでのトークン所有権の移転を可能にすることで、資産移転の方法を一変させました。
これは暗号通貨において特に明らかで、仲介者なしで素早くトークンをやり取りできるようになりました。
しかし、セキュリティトークン（証券化されたトークン）の場合、法律への準拠が必要となり、事態はもっと複雑です。
これらのトークンは特定のルールに従って、適格な投資家だけが保持できるように管理される必要があります。

現在のイーサリアムプロトコルは多機能ですが、セキュリティトークン特有の問題をすべて解決するわけではありません。
それを解決するために、ERC3643という新しい標準が提案されています。
この標準は、セキュリティトークンの発行から取引までのライフサイクルを管理し、各ステップでコンプライアンス（法令遵守）を強制するフレームワークを提供することを目的としています。
また、規制の変更やトークン保持者の状況に応じてトークンを一時停止や凍結する機能も備えています。

この標準は、オンチェーンアイデンティティシステムと連動して動作し、信頼できる発行者が出した証明を通じて投資家の身元や資格を検証します。
これにより、セキュリティトークンの取引が法的および規制上の要件を満たすことが保証されます。

ERC3643はセキュリティトークンを安全に、法律に従って取引できるようにするためのルールとツールを提供します。
これにより、ブロックチェーンのメリットを証券の世界に拡張し、資本市場をより進化させることを目指しています。

仕様

提案されたERC3643標準は、セキュリティトークンの管理と取引をより安全でスムーズに行うための一連のルールを定めています。
以下は、この標準に必要な主な要件を説明したものです。

ERC20との互換性

この新しい標準は既存のERC20トークン標準と互換性があり、それに基づいて動作しますが、セキュリティトークン特有の機能を追加しています。

ERC20については以下の記事を参考にしてください。

オンチェーンアイデンティティシステムの使用

投資家の身元を確認し、規制に準拠していることを保証するために、オンチェーンでのアイデンティティ管理システムと連携します。

コンプライアンスルールの適用

規制当局やトークン発行者によって設定された、投資家の資格やトークン自体のルールを適用できます。

トランスファーチェックインターフェース

トークンを送信する前に、そのトランスファーが成功するかどうかを事前にチェックできる機能があります。

リカバリーシステム

投資家が自分のプライベートキーにアクセスできなくなった場合に備えた復旧手段を提供します。

トークンの凍結

必要に応じて、投資家のウォレット内のトークンを部分的または完全に凍結することができます。

トークンの一時停止

トークンの取引を一時的に停止することが可能です。

トークンの`mint`（鋳造）と`burn`（焼却）

新しいトークンを作成したり、既存のトークンを無効にしたりすることができます。

エージェントロールとオーナーロール

特定のロールを持つアカウントがトークンの特定の操作を行えるようにします。

エージェントによる強制転送

必要に応じて、エージェントが他のウォレットからトークンを転送することを強制できます。

一括トランザクション

複数のトランザクションを一度に処理し、ガス代を節約しながら効率的に取引を行えます。

ERC3643の各トランスファーはコンプライアンスチェックを伴い、安全で規制に準拠した取引が保証されます。
この標準は、セキュリティトークンの取引をより透明かつ効率的にし、資本市場の発展に貢献することを目的としています。

エージェント・ロール・インターフェース

提案された標準における「エージェントロール」とは、スマートコントラクトの特定の機能へのアクセスを許可されたアドレスを指します。

エージェントはスマートコントラクトの管理人のようなもので、特定の操作を行うことができます。

interface IAgentRole {

  // events
  event AgentAdded(address indexed _agent);
  event AgentRemoved(address indexed _agent);
  
  // functions
  // setters
  function addAgent(address _agent) external;
  function removeAgent(address _agent) external;

  // getters
  function isAgent(address _agent) external view returns (bool);
}

IAgentRoleインターフェースは、エージェントを管理するためのルールと機能を定義しています。
具体的には、以下の機能があります。

addAgent
- 新しいエージェントを追加する。
removeAgent
- 既存のエージェントを削除する。
isAgent
- 特定のアドレスがエージェントであるかどうかを確認する。

このインターフェースを通じて、オーナーロール（通常はトークンの発行者）はエージェントを管理することができます。
エージェントが追加されるとAgentAddedイベントが発生し、エージェントが削除されるとAgentRemovedイベントが発生します。
これにより、誰がいつエージェントに追加または削除されたのかを追跡することが容易になります。

この標準の文脈では、トークンコントラクトやアイデンティティレジストリなど、セキュリティトークンに関連するコントラクトは、このIAgentRoleインターフェースと互換性がある必要があります。
つまり、これらのコントラクトはエージェントの管理をサポートし、エージェントによる特定の操作を許可するように設計されている必要があります。

エージェントロールはセキュリティトークンの適切な管理と規制の遵守を確保するための重要なメカニズムです。
エージェントは、トークンシステム内で特定の重要な機能を実行する権限を持つ信頼できる人々であり、その追加や削除は厳格に管理されます。

メイン関数

Transfer

T-REXを使用したトランスファー（送金）には、いくつかの重要な条件があります。
これらの条件はトークンの安全性と規制遵守を確保するために必要です。

自由残高

送信者は、凍結されていないトークンを含め、送金額をカバーする十分な残高を持っている必要があります。

ホワイトリストと検証

受信者は、アイデンティティレジストリに登録され、適切なクレーム（証明情報）を持っていることが確認されていなければなりません。

ウォレットの凍結状態

送信者と受信者のウォレットは凍結されていてはなりません。
凍結されているウォレットから、または凍結されているウォレットへの送金はできません。

トークンの状態

トークンが一時停止されている場合は送金できません。

コンプライアンスルール

送金はコンプライアンススマートコントラクトが定義するルールを全て満たしている必要があります。
これは、法律や規制を遵守するために重要です。

実際のtransfer関数は、これらの条件をチェックするコードを含んでいます。
もし条件を満たさない場合、送金は実行されません。
例えば、ウォレットが凍結されているか、受信者が適切に検証されていない場合などです。

transferFrom関数も基本的にはtransfer関数と同じように動作しますが、他の人のトークンを送金する時に使います。
一方、mint（トークンの発行）とforcedTransfer（強制送金）関数は受け取りアドレスがホワイトリストに載っていて検証されている限り実行できますが、他のコンプライアンスルールは適用されません。burn（トークンの焼却）関数はこれらすべてのチェックをバイパスし、トークンを無効にすることができます。

これらのルールと関数は、T-REXが提供するセキュリティと規制遵守のレベルを保ちながら、ユーザーがトークンを効率的に送金できるように設計されています。

isVerified

この関数はトークンを送る時に重要です。
受け取る人がトークンを保持する資格があるかどうかを確認します。
具体的には、受け取る人のウォレットアドレスがトークンのアイデンティティレジストリに登録されているか、そしてその人のアイデンティティコントラクトに必要な証明（クレーム）が含まれているかをチェックします。
これらが信頼できる発行者によって承認されていれば、受け取るアドレスは「検証済み」と見なされます。
この関数がtrueを返すと、transferは次のステップに進むことができます。

canTransfer

この関数も送金時に使用されますが、より広範な視点からtransferをチェックします。
例えば、特定の国での保有者数の上限や投資家ごとのトークン数の上限など、トークン全体に適用されるコンプライアンスルールを確認します。
これらのルールに違反するtransferは許可されません。
transferがすべてのルールに従っていれば、関数はtrueを返し、そうでなければfalseを返して送金が拒否されます。

他の関数

ERC3643には他にも多くの関数があり、それぞれがトークンの異なる側面を管理します。
これらの詳細はインターフェースフォルダやTokenyのT-REXリポジトリで確認できます。

これらの機能はすべて、セキュリティトークンの取引が安全で効率的かつ規制に準拠して行われることを保証するために設計されています。
T-REXシステムは、これらのチェックを通じて、トークンの送金と管理が法的に適切であることを保証します。

トークンインターフェース

ERC3643は、通常のERC20トークンよりも厳格な規制とセキュリティを必要とするセキュリティトークンのための特別な標準です。
この標準には、transferを安全に管理するための追加の機能が備わっています。

条件付き送金

transferやtransferFromのような送金関数は、条件付きで動作します。
つまり、送金が行われる前に、いくつかのチェックが行われます。
これには、受取アドレスが適切に検証された投資家であるかどうかや、トランザクションが特定の規制基準を満たしているかどうかが含まれます。

検証済み対象者への限定

許可されたトークンは、適切に検証されたアドレスにのみ送金できます。
これにより、資格のないアドレスや承認されていない投資家のウォレットにトークンが保持されるのを防ぎます。

トークンの回復

投資家がウォレットのプライベートキーへのアクセスを失った場合に備えて、セキュリティトークンを回復する機能があります。
回復されたトークンの履歴は、透明性を保つためにブロックチェーン上で維持されます。

追加機能

ERC3643トークンは、供給管理、送金ルール、ロックアップ、その他のセキュリティ管理に必要な追加機能を実装しています。
これにより、オーナーやエージェントはトークンの供給と規則を柔軟に管理できます。

エージェントとオーナー

この標準はERC173に依存しており、オーナーはエージェントを任命する責任を持ちます。
トークンコントラクトはIAgentRoleインターフェースと互換性がある必要があります。

ERC173については以下の記事を参考にしてください。

関数の詳細

関数の詳細な説明はインターフェースフォルダで見ることができます。

これにより、ERC3643がセキュリティトークンの管理と取引をどのようにサポートするかをより深く理解できます。

interface IERC3643 is IERC20 {

   // events
    event UpdatedTokenInformation(string _newName, string _newSymbol, uint8 _newDecimals, string _newVersion, address _newOnchainID);
    event IdentityRegistryAdded(address indexed _identityRegistry);
    event ComplianceAdded(address indexed _compliance);
    event RecoverySuccess(address _lostWallet, address _newWallet, address _investorOnchainID);
    event AddressFrozen(address indexed _userAddress, bool indexed _isFrozen, address indexed _owner);
    event TokensFrozen(address indexed _userAddress, uint256 _amount);
    event TokensUnfrozen(address indexed _userAddress, uint256 _amount);
    event Paused(address _userAddress);
    event Unpaused(address _userAddress);


    // functions
    // getters
    function onchainID() external view returns (address);
    function version() external view returns (string memory);
    function identityRegistry() external view returns (IIdentityRegistry);
    function compliance() external view returns (ICompliance);
    function paused() external view returns (bool);
    function isFrozen(address _userAddress) external view returns (bool);
    function getFrozenTokens(address _userAddress) external view returns (uint256);

    // setters
    function setName(string calldata _name) external;
    function setSymbol(string calldata _symbol) external;
    function setOnchainID(address _onchainID) external;
    function pause() external;
    function unpause() external;
    function setAddressFrozen(address _userAddress, bool _freeze) external;
    function freezePartialTokens(address _userAddress, uint256 _amount) external;
    function unfreezePartialTokens(address _userAddress, uint256 _amount) external;
    function setIdentityRegistry(address _identityRegistry) external;
    function setCompliance(address _compliance) external;

    // transfer actions
    function forcedTransfer(address _from, address _to, uint256 _amount) external returns (bool);
    function mint(address _to, uint256 _amount) external;
    function burn(address _userAddress, uint256 _amount) external;
    function recoveryAddress(address _lostWallet, address _newWallet, address _investorOnchainID) external returns (bool);

    // batch functions
    function batchTransfer(address[] calldata _toList, uint256[] calldata _amounts) external;
    function batchForcedTransfer(address[] calldata _fromList, address[] calldata _toList, uint256[] calldata _amounts) external;
    function batchMint(address[] calldata _toList, uint256[] calldata _amounts) external;
    function batchBurn(address[] calldata _userAddresses, uint256[] calldata _amounts) external;
    function batchSetAddressFrozen(address[] calldata _userAddresses, bool[] calldata _freeze) external;
    function batchFreezePartialTokens(address[] calldata _userAddresses, uint256[] calldata _amounts) external;
    function batchUnfreezePartialTokens(address[] calldata _userAddresses, uint256[] calldata _amounts) external;
}

アイデンティティ・レジストリ・インターフェイス

アイデンティティレジストリは、投資家の身元情報を管理するためのシステムです。
これは、特定のウォレットアドレスを投資家のアイデンティティスマートコントラクトと関連付ける役割を果たします。
さらに、投資家の居住国に対応する国コードもリンクされており、このコードはISO-3166標準に基づいて設定されます。

ISO-3166

ISO-3166は、国際標準化機構（ISO）によって定められた国や地域を識別するためのコードの標準です。
この標準は、世界中の国々や特定地域を一意に識別するために広く使用されており、データ交換や情報処理など多くの文脈で便利です。

ISO-3166には主に以下の3つの部分があります。

ISO-3166-1

国と地域のコードを定義しており、3つの異なるコードフォーマットがあります。

アルファ-2
- 2文字の国コード（例：JPは日本、USはアメリカ合衆国）。
アルファ-3
- 3文字の国コード（例：JPNは日本、USAはアメリカ合衆国）。
数値コード
- 3桁の数字で表される国コード。

ISO-3166-2

国内の地域区分（州や県など）のコードを定義しています。
この部分は各国の主要な地域を識別するために使用され、国コードと組み合わせて使用されることが多いです（例：JP-13は日本の東京都）。

ISO-3166-3

過去に使用されていたが、現在はもはや使用されていない国のコードを記録するために使用されます。
これは主に歴史的な文書やデータのために保持されています。

ISO-3166コードは、ウェブサイトの国際化、国際郵便サービス、グローバルなデータベース管理、国際貿易など、さまざまな国際的な文脈で広く利用されています。
また、国際的な旅行や通信、地理的な分析などの分野でも重要な役割を果たしています。

isVerified()という関数は、ユーザーのアイデンティティコントラクトに記録されているクレーム（証明）がセキュリティトークンの要件に適合しているかどうかを確認します。
この関数がtrueを返す場合、そのアドレスは適格であるとみなされます。

ERC3643の文脈でアイデンティティレジストリを運用するためには、IAgentRoleインターフェースと互換性がある必要があります。
これは、オーナーがエージェントを任命できるようにするためです。
エージェントは、アイデンティティをレジストリに追加したり削除したりする権限を持っています。
オーナーは必要に応じて自分自身をエージェントとして設定することも可能です。

さらに、このシステムはIClaimIssuerとIIdentityインターフェースも必要とします。
これは、アイデンティティの適格性をチェックするために重要な役割を果たします。

アイデンティティレジストリの機能や仕組みの詳細はインターフェースフォルダで確認できます。

これらの情報を通じて、セキュリティトークンの取引において重要な規制遵守とアイデンティティ管理がどのように行われるかを理解できます。

interface IIdentityRegistry {


    // events
    event ClaimTopicsRegistrySet(address indexed claimTopicsRegistry);
    event IdentityStorageSet(address indexed identityStorage);
    event TrustedIssuersRegistrySet(address indexed trustedIssuersRegistry);
    event IdentityRegistered(address indexed investorAddress, IIdentity indexed identity);
    event IdentityRemoved(address indexed investorAddress, IIdentity indexed identity);
    event IdentityUpdated(IIdentity indexed oldIdentity, IIdentity indexed newIdentity);
    event CountryUpdated(address indexed investorAddress, uint16 indexed country);


    // functions
    // identity registry getters
    function identityStorage() external view returns (IIdentityRegistryStorage);
    function issuersRegistry() external view returns (ITrustedIssuersRegistry);
    function topicsRegistry() external view returns (IClaimTopicsRegistry);

    //identity registry setters
    function setIdentityRegistryStorage(address _identityRegistryStorage) external;
    function setClaimTopicsRegistry(address _claimTopicsRegistry) external;
    function setTrustedIssuersRegistry(address _trustedIssuersRegistry) external;

    // registry actions
    function registerIdentity(address _userAddress, IIdentity _identity, uint16 _country) external;
    function deleteIdentity(address _userAddress) external;
    function updateCountry(address _userAddress, uint16 _country) external;
    function updateIdentity(address _userAddress, IIdentity _identity) external;
    function batchRegisterIdentity(address[] calldata _userAddresses, IIdentity[] calldata _identities, uint16[] calldata _countries) external;

    // registry consultation
    function contains(address _userAddress) external view returns (bool);
    function isVerified(address _userAddress) external view returns (bool);
    function identity(address _userAddress) external view returns (IIdentity);
    function investorCountry(address _userAddress) external view returns (uint16);
}

アイデンティティ・レジストリー・ストレージ・インターフェイス

アイデンティティレジストリストレージは、特定のセキュリティトークンに関連する承認された投資家の情報を保存するシステムです。
このシステムは以下のように機能します。

アイデンティティの保存

投資家のアイデンティティ情報は、KYC（顧客確認）と適格性チェックをクリアした後、このストレージに登録されます。
これには投資家のウォレットアドレスや関連する国コードなどが含まれます。

分離された機能とストレージ

アイデンティティレジストリストレージの目的は、アイデンティティの確認や管理のための機能と、それらの情報を保存するストレージを分離することです。
これにより、1つのアイデンティティレジストリコントラクトで複数のセキュリティトークンを管理できるようになり、効率が向上します。

エージェントの役割

アイデンティティレジストリストレージはエージェントによって管理されます。
エージェントはオーナーによって任命され、投資家のアイデンティティを追加または削除する権限を持ちます。
オーナーは自分自身をエージェントとして設定し、直接ストレージを管理することもできます。

`isVerified()`関数

この関数は、送金取引の際に受取人が適格な投資家であるかどうかをチェックするために使用されます。
受取人のアイデンティティ情報がレジストリに登録され、適切なクレームがある場合にtrueを返します。

アイデンティティレジストリストレージの機能や仕組みの詳細はインターフェースフォルダで確認できます。

このように、アイデンティティレジストリストレージは、セキュリティトークンの取引が適格な投資家間でのみ行われることを保証し、トークン発行者が投資家の情報を効率的に管理できるようにするための重要なシステムです。

interface IIdentityRegistryStorage {

    //events
    event IdentityStored(address indexed investorAddress, IIdentity indexed identity);
    event IdentityUnstored(address indexed investorAddress, IIdentity indexed identity);
    event IdentityModified(IIdentity indexed oldIdentity, IIdentity indexed newIdentity);
    event CountryModified(address indexed investorAddress, uint16 indexed country);
    event IdentityRegistryBound(address indexed identityRegistry);
    event IdentityRegistryUnbound(address indexed identityRegistry);

    //functions
    // storage related functions
    function storedIdentity(address _userAddress) external view returns (IIdentity);
    function storedInvestorCountry(address _userAddress) external view returns (uint16);
    function addIdentityToStorage(address _userAddress, IIdentity _identity, uint16 _country) external;
    function removeIdentityFromStorage(address _userAddress) external;
    function modifyStoredInvestorCountry(address _userAddress, uint16 _country) external;
    function modifyStoredIdentity(address _userAddress, IIdentity _identity) external;

    // role setter
    function bindIdentityRegistry(address _identityRegistry) external;
    function unbindIdentityRegistry(address _identityRegistry) external;

    // getter for bound IdentityRegistry role
    function linkedIdentityRegistries() external view returns (address[] memory);
}

コンプライアンス・インターフェイス

コンプライアンスコントラクトは、セキュリティトークンの取引が特定の法的要件やルールに従って行われることを保証するために使用されます。
このコントラクトは、以下のような機能を持っています。

ルールの設定

投資家の国籍に基づいて、各国の投資家の最大数や投資家ごとのトークンの最大保有量など、トークンの提供に関するルールを定義します。

カスタマイズ性

コンプライアンスコントラクトはオーダーメイドで作成することができ、または汎用的な形でデプロイし、必要に応じて外部のコンプライアンスモジュールを追加・削除してカスタマイズすることができます。

トランザクションチェック

トークンの各トランザクションごとにトリガーされ、そのトランザクションが定められたルールに準拠しているかどうかをチェックします。
ルールに準拠していればtrueを、そうでなければfalseを返し、トランザクションの実行を制御します。

オーナーシップとエージェントロール

ERC173に基づいてコントラクトの所有者が定義され、オーナーはコンプライアンスの設定とトークンコントラクトへのバインディングの責任を持ちます。
また、オーナーはコントラクト内でエージェントを指定し、コンプライアンス関連の操作を管理させることができます。

このように、コンプライアンスコントラクトはトークンの提供と取引が適切に管理され、規制に準拠することを保証するための重要なツールです。
各機能の詳細な説明はインターフェースフォルダ内で確認することができます。

interface ICompliance {

    // events
    event TokenBound(address _token);
    event TokenUnbound(address _token);

    // functions
    // initialization of the compliance contract
    function bindToken(address _token) external;
    function unbindToken(address _token) external;

    // check the parameters of the compliance contract
    function isTokenBound(address _token) external view returns (bool);
    function getTokenBound() external view returns (address);

    // compliance check and state update
    function canTransfer(address _from, address _to, uint256 _amount) external view returns (bool);
    function transferred(address _from, address _to, uint256 _amount) external;
    function created(address _to, uint256 _amount) external;
    function destroyed(address _from, uint256 _amount) external;
}

信頼された発行者のレジストリ・インターフェイス

信頼できる発行者のレジストリは、セキュリティトークンを安全に管理するためのシステムです。
このシステムは、特定のセキュリティトークンに関連する、信頼できるクレーム発行者のアドレスを保管しています。クレーム発行者とは、投資家の身元や資格を証明するクレーム（証明書のようなもの）を発行する機関のことです。

投資家がトークンを保持するためには、その投資家のアイデンティティコントラクト（IIdentity）に、このレジストリに登録されている信頼できる発行者からの署名付きのクレームが必要です。
つまり、投資家がトークンを保持する資格があることが確認されなければなりません。

このシステムの管理責任はコントラクトのオーナーにあります。
オーナーはERC173の基準に従い、信頼できる発行者のリストを管理（追加、削除、更新）することができます。
この柔軟性により、トークンの法的要件やポリシーの変更に応じて、レジストリを適宜調整することが可能です。

信頼できる発行者のレジストリの機能とその操作方法の詳細は、インターフェースフォルダ内で提供されています。

この情報を通じて、セキュリティトークンの適格性と取引の安全性を確保するためのしくみがどのように構築されているかを理解することができます。

Claim Topics Registry インターフェイス

クレームトピックスレジストリは、セキュリティトークンのために特定の種類のクレーム（証明や属性など）を管理するコントラクトです。
このコントラクトは、トークン所有者に関連する重要な情報をカテゴリ別に整理して保存します。
トークン所有者のアイデンティティコントラクト（IIdentity）は、このレジストリに記録されているクレームトピックに基づいて、適切な証明を含む必要があります。
これにより、トークンの保有資格や取引の合法性が確認されます。

オーナーはERC173基準に従ってこのレジストリの所有権を持ち、必要に応じてクレームトピックを追加したり削除したりすることができます。
つまり、オーナーはトークンの法的要件やポリシーに合わせてレジストリをカスタマイズできる権限を持っています。

このシステムの具体的な操作方法や機能の詳細は、インターフェースフォルダ内の文書で確認できます。

この情報により、セキュリティトークンがどのように適切なクレーム情報を管理し、取引の透明性と合法性を保つかを理解することができます。

interface IClaimTopicsRegistry {

    // events
    event ClaimTopicAdded(uint256 indexed claimTopic);
    event ClaimTopicRemoved(uint256 indexed claimTopic);

    // functions
    // setters
    function addClaimTopic(uint256 _claimTopic) external;
    function removeClaimTopic(uint256 _claimTopic) external;

    // getter
    function getClaimTopics() external view returns (uint256[] memory);
}

補足

Transfer制限

セキュリティトークンの送金は、一般的なユーティリティトークンと異なり、多くの条件を満たす必要があります。
これらの条件は、投資家のウォレット状況、送受信者の身元や資格（KYCプロセスの完了、認定投資家かどうかなど）、またはトークン自体に設定されたルール（投資家数の上限や単一投資家の保有割合の上限など）に関連する可能性があります。
ERC20トークンでは、balanceOfやallowance関数を使って送金が成功するか事前にチェックできますが、セキュリティトークンではT-REX標準が導入したcanTransferやisVerified関数を使い、より広範なコンプライアンスルールと投資家のアイデンティティ適格性をチェックします。
これらのチェックに合格しない場合、送金は失敗します。
また、送受信者のアドレスが凍結されている、送信者の利用可能残高が不足している、トークンが一時停止されている場合も送金はブロックされます。

アイデンティティ管理

セキュリティトークンの送金のセキュリティとコンプライアンスは、オンチェーンアイデンティティ管理を通じて強化されます。

アイデンティティコントラクト（Identity contract）

各投資家にユニークな識別子を提供します。

クレーム

投資家の身元や資格を証明します。

アイデンティティストレージ/レジストリ（Identity Storage/Registry）

すべてのアイデンティティ情報とウォレットを保存し、送金時に投資家の適格性を確認するために使用されます。

これらのシステムを通じて、トークンの取引が適法かつ安全に行われることが保証されます。

トークンのライフサイクル管理

T-REX標準は、セキュリティトークンを効果的に管理するための包括的な方法を提供します。
トークンの発行から適格な投資家間の送金、ライフサイクルの各段階でのコンプライアンスルールの適用まで、トークンの全過程をサポートします。
さらに、トークンを一時停止したり凍結したりする機能も備えており、これにより規制要件に応じて柔軟に対応し、トークンやその保有者の状況が変わったときに対応できます。

追加のコンプライアンスルール

T-REXは、モジュール式のコンプライアンスを通じて、さまざまな追加ルールを実装できる柔軟性を提供します。
これにより、投資家の数に上限を設けたり、特定の投資家が保有できるトークンの割合を制限したり、特定のタイプの投資家間の送金を制限するなど、多岐にわたる規制を設定できます。
これにより、発行者はトークンのコンプライアンスを独自のニーズや規制環境に合わせてカスタマイズできます。

エージェント関連機能

エージェントスコープ機能を標準インターフェースに組み込むことで、よりセキュアで適応性のあるトークン管理が可能になります。
自動化されたシステムやスマートコントラクトがエージェントロールを担い、mintやburn、凍結などの操作をプログラム的に実行できます。
これにより、さまざまなシナリオに応じて、トークンの管理を自動化し、規制トリガーに迅速に対応できます。

これらの機能は、異なるERC3643トークンと対話するさまざまなシステムが共通のインターフェースを使用できるように標準化されています。
これにより、エコシステム全体で機能する標準化されたツールやインターフェースが実現され、ERC3643は将来にわたって柔軟かつ広範な運用モデルをサポートできるようになります。

後方互換性

T-REXトークンは、以前からあるERC20とERC173のシステムやコントラクトと問題なく連携できるように設計されています。
これにより、T-REXトークンは既存の多くのウォレットや取引所で扱うことが可能です。
また、T-REXトークンは、投資家の身元や資格などの情報を保持するアイデンティティコントラクトに関連付けられたクレームを検証するために、クレームホルダーコントラクトと通信する機能も持っています。
これにより、T-REXトークンは投資家のアイデンティティを確認し、取引が適切な規制とコンプライアンスを満たしているかを確認することができるのです。

セキュリティ

この仕様は、KaperskyとHackenというセキュリティ専門の監査機関によってチェックされましたが、特に問題となるセキュリティ上の問題点は見つかりませんでした。
監査は主にTokenyによるT-REX標準の具体的な実装に焦点を当てていましたが、T-REX標準自体の基本的な原則も詳細に検討し、承認されました。
これらの原則が監査チームによって承認されたことで、T-REX標準が非常に堅牢であり、大きなセキュリティ上の問題を抱えていないことが保証されています。

引用

Joachim Lebrun (@Joachim-Lebrun), Tony Malghem (@TonyMalghem), Kevin Thizy (@Nakasar), Luc Falempin (@lfalempin), Adam Boudjemaa (@Aboudjem), "ERC-3643: T-REX - Token for Regulated EXchanges," Ethereum Improvement Proposals, no. 3643, July 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-3643.

最後に

今回は「機関投資家向けのセキュリティ・トークン・コントラクトで、セキュリティ・トークンの管理とコンプライアンスに基づくtransferのためのインターフェースの仕組みを提案している規格であるERC3643」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！