Equity Tokens

[mrosendin]

The proposed XLS-33d Multi-Purpose Token standard is presented as a possible solution to tokenized equity securities, but IMO it falls short of an ideal implementation. My specific concerns:

1. The ideal equity token spec should allow a token to be partitioned into multiple security classes (rather than issuing multiple tokens per class)
2. It should follow the design philosophy of the Open Cap Format (OCF) schema which uses the concept of balance securities. To understand the concept please review how the OCF handles stock transfers.

Furthermore, like XLS-33d, features for token freeze and clawback are required. Specified accounts other than the issuer should be able to act as a transfer agent on behalf of the issuer. XLS-40 Decentralized Identity should also be incorporated with a shareholder registry that specifies which accounts are authorized to hold the token.

Once concern that I haven't thought through yet is how arbitrary compliance rulesets can be enforced by token (e.g., as defined in the shareholder agreement), share class (e.g., as defined in stock plan or corporate charter), or individual issuances (e.g., vesting conditions). It could be simplified such that the issuer or transfer agent has to conditionally approve ALL transfers without any on-chain compliance validation checks.

References:

• Equity Token Standard: ERC Draft
• XLS-33d: Multi-Purpose Tokens

@sappenin @intelliot @WietseWind @mvadari @ledhed2222

[shashwatmittal92]

@mrosendin, thanks so much for your feedback.
To address some of your concerns:

1. Freeze and Clawback will be available for the Multi-Purpose token standard.
2. To your DID point, a spec is in progress XLS-70. On-chain VCs, once available, will allow for incorporating shareholder registry in the way you have described.

Your feedback about the Transfer agent and implementation of the arbitrary ruleset is well taken. Unfortunately, we don't have the best solution for it yet, but I agree it should be solved.

Can you expand a little bit more about the tradeoff between having the token standard itself partition a token into multiple security classes and issuing multiple tokens per class? I am just wondering if this solution should be solved at a blockchain level, at the software application level, or through a metadata pointer.