合規是Security Token系統非常重要的，可能是最重要的方面，本文聚焦於合規系統的設計。
合規系統的設計模式
簡而言之，我們的合規系統是一個邏輯可裝配的合規元件的網路。
· 合規是作為唯一的簡單模組介面被Security Token核心使用，合規本身的複雜結構對核心是透明的，並不會出現許多合規模組。合規本身自成體系。
· 一個可配置的使用投資人claim組合邏輯來檢查合規性的通用元件。更具體說，這個元件訪問ERC780 Claim Registry，得到投資人Claim，檢查合規條件是否得到滿足。這個合規條件是用一個如下格式的布林邏輯表示式來表達：
“jurisdiction==US&&certificate=AccreditedInvestor||jurisdiction==sigapore&&certificate==**”
每個Security Token都被各自配置一個這樣的表示式。顯然，這個元件本身有很高的複用價值，能夠滿足相當一部分專案的合規需求。
· 對元件進行邏輯裝配的與、或邏輯元件。這些邏輯元件將其他元件連成邏輯網路
· 適配其他數字身份技術的元件，比如ERC735、ERC734 Identity Proxy的介面卡
· 不斷擴充套件的其他元件
合規合約系統的設計主題是“組合裝配”，並且可以具有任意深度的裝配層次，這種遞迴裝配結構可以提供幾乎不受硬性約束的擴充套件能力與靈活性，以適應不同的數字身份及其證書的來源、技術與形式，多國家多司法管轄區的要求，以及Security Token在政府金融法規方面可能的進步與變化的預期。合規是Security Token最主要最本質的方面，與此相適應的技術設計也是Magic Circle的重大任務。
案例
下面我們分析幾個組合裝配合規元件的場景模式案例：
場景一：多司法管轄區支援
要求投資人可以是美國人或者新加坡人或者日本人，並具有相應國家各自認定的投資人資質。
· 三個元件各自負責一個司法管轄區。當投資人滿足該元件的合規檢查時返回真
· 或邏輯元件將三個司法管轄區元件進行或邏輯組合
· 任何這三個國家的投資人訪問這個組合時，必有其中一個元件返回而滿足合規檢查，三國以外的投資人或者不具有相應資格的三國人會失敗
場景2：OnchainID的適配
OnchainID所採用的數字身份規範是ERC734、ERC735身份代理的方式。現在的情況是：
· 一部分投資人持有Magic Circle數字身份錢包，申請了合格投資人Claim並且將Claim上鍊到ERC780
· 另一部分投資人是TX發行平臺使用者，並透過自己擁有的Identity Proxy合約例項
· 配置合規組合結構，同時支援兩種投資人合規購買
如上圖所示構建的邏輯合規元件即可滿足上述合規檢查要求
· 配置OnchainID介面卡。OnchainID中的identity是基於ERC734，宣告部分基於ERC35。IdentityRegistry的地址已知，我們用到的合約方法有：
用這些方法可以驗證投資人是否擁有數字身份並是合格投資人。
· 另外一個元件是基於ERC780的數字身份與宣告系統。投資人是透過數字身份錢包和宣告網路獲得合格投資人資質的。
· 一個或元件將上述兩個元件進行邏輯組合，這樣來自於異構數字身份與合規系統的投資人都可以被支援。
往前一小步
不同司法管轄區的投資人，有些使用了Magic Circle數字身份錢包，有些是TX發行平臺投資人使用者。
解決方案：構建案例1和案例2的邏輯組合即可，不再贅述。（說明：透過讓TX投資人使用者安裝數字身份錢包，再透過claim provider網路將Identity Proxy中的Claim轉化釋出到ERC780, 是另一種路徑，做何選擇取決於實施條件）
演進路徑
組合裝配的合規系統同樣提供了演進路徑。
組合裝配邏輯元件是基礎結構
目前ConfigurableComplianceService元件本身就能夠滿足一部分組合配置要求，可支援發行專案基本實施
鎖倉，百分比，持有者允許的最大token額度，最大持有者數目等的約束元件
早期實施專案如果出現ConfigurableComplianceService無法處理的情況，可以開發定製性的合規元件
定製性元件的累積和抽象，沉澱出有複用價值的元件
達到普遍的複用，降低專案成本，提供強大的工具性支援
結語
與Defi不同，Security Token 合規問題需要直面現實世界的金融系統複雜性的挑戰，傳統IT平臺設計開發中形成的模式與技巧對於應對這一挑戰是不可或缺的。
