ERC-7518: Dynamic Compliant Interop Security Token

Abstract

---

This proposal is a security token standard that extends ERC-1155 to provide a flexible framework for managing compliant real-asset security tokens. It introduces the concept of partitions, where each tokenId represents a distinct partition with its own set of rights and privileges. This makes it suitable for various use cases, particularly semi-fungible asset management. The standard also includes features like token locking, forced transfers for recovery, address freezing, payouts, and dynamic compliance management using off-chain vouchers.

Motivation

---

The growing demand for tokenized real-world assets necessitates a token standard that can accommodate the unique requirements of security tokens. Existing standards, while powerful, do not fully address the need for flexible partitioning and comprehensive compliance management.

This standard builds upon ERC-1155 by introducing partitions, allowing for the creation of semi-fungible tokens representing fractional ownership, different share classes, or other distinct units within a single token contract. This flexibility is crucial for tokenizing complex real-world assets like real estate or funds.

Furthermore, it includes features essential for security tokens, such as token locking for vesting or holding periods, forced transfers for recovery in case of lost keys, address freezing for regulatory compliance, efficient payout mechanisms, and dynamic compliance management using off-chain vouchers.

By providing a standardized interface for these features, this proposal aims to facilitate the development of interoperable and compliant security token ecosystems.

Partition-Based Architecture Benefits

The partition paradigm offers significant flexibility and power in managing security tokens:

1. Dynamic Allocation : Partitions allow for dynamic allocation of tokens between different classes or categories. For example, in a real estate tokenization scenario, an issuer can initially allocate tokens to a Reg D partition for accredited U.S. investors and a "Reg S" partition for non-U.S. investors. As the offering progresses and demand shifts, the issuer can dynamically mint tokens into the appropriate partition based on the investor's eligibility, ensuring optimal distribution and compliance.
2. Temporary Non-Fungibility : Partitions enable temporary non-fungibility of tokens. In some cases, securities may need to be treated as non-fungible for a certain period, such as tokens of the same underlying asset sold at different offerings. By assigning tokens to specific partitions, issuers can enforce these restrictions and maintain the necessary segregation between them, but merge them at a later point to prevent liquidity fragmentation. Merger occurs by creating a new joint partition, a deploying a merger contract where users can deposit old partitioned tokens to receive new joint partition token.
3. Granular Compliance : Each partition can have its own set of compliance rules and transfer restrictions. This allows for more granular control over token transfers based on the specific characteristics of each partition. For instance, a partition representing a particular share class may have different transfer restrictions or payout rights compared to other partitions.
4. Efficient Asset Management : Partitions streamline the management of complex asset structures. Instead of deploying separate contracts for each share class or asset category, issuers can manage multiple partitions within a single proposed contract, reducing deployment costs and simplifying overall asset management.

Real World Use Cases

Use Case 1: Tokenization of Commercial Real Estate

In this use case, a commercial real estate property with 100 floors is being tokenized using this proposal. Each floor is represented as a unique non-fungible token (NFT) partition, allowing for fractional ownership and separate management of individual floors.

1. Property Representation: The entire commercial property is tokenized using the proposed contract, with each floor being assigned a unique tokenId representing an NFT partition.

2. Fractional Ownership: Each floor's NFT partition can be divided into multiple fungible tokens, enabling fractional ownership. For instance, if a floor is divided into 100 tokens, multiple investors can own portions of that floor.

3. Dynamic Pricing: Since each floor is a separate partition, the pricing of tokens within a partition can be adjusted dynamically based on factors such as floor level, amenities, or market demand. This flexibility allows for accurate representation of the varying values of different floors.

4. Transfer of Ownership: The ownership of each floor's NFT partition can be transferred seamlessly to token holders using the safeTransferFrom function. This enables the seamless transfer of ownership rights for specific floors.

5. Compliance Management: Different compliance rules and transfer restrictions can be applied to each partition (floor) based on regulatory requirements or issuer-defined rules. The canTransfer function can be used to enforce these rules before allowing transfers.

6. Payouts: The payout and batchPayout functions can be used to distribute rental income, dividends, or other payouts to token holders of specific floor partitions efficiently.

By leveraging proposal, this use case demonstrates the ability to tokenize complex real estate assets while maintaining granular control over ownership, pricing, compliance, and payouts for individual units within the property.

Use Case 2: Tokenization of Securities with Reg S and Reg D Partitions

In this use case, a company is tokenizing its securities and wants to comply with different regulations for U.S. accredited investors (Reg D) and non-U.S. investors (Reg S).

1. Initial Partitions: The company deploys an proposed standard and creates two partitions: one for Reg D investors (accredited U.S. investors) and another for Reg S investors (non-U.S. investors).

2. Dynamic Allocation: As the offering progresses, the company can dynamically mint tokens into the appropriate partition based on investor eligibility. For example, if a U.S. accredited investor wants to participate, tokens can be minted in the Reg D partition, while tokens for non-U.S. investors are minted in the Reg S partition.

3. Compliance Management: Each partition can have its own set of compliance rules and transfer restrictions. The canTransfer function can be integrated with off-chain compliance services to verify the eligibility of a transfer based on the specific rules for each partition.

4. Temporary Non-Fungibility: During the initial offering period, tokens in the Reg D and Reg S partitions may need to be treated as non-fungible due to different regulatory requirements. However, after the holding period, the company can create a new joint partition and allow token holders to deposit their old partitioned tokens to receive the new joint partition tokens, merging the two classes.

5. Payouts: The payout and batchPayout functions can be used to distribute dividends, interest payments, or other payouts to token holders in each partition based on their respective rights and privileges.

By utilizing the proposal, this use case demonstrates the ability to tokenize securities while maintaining compliance with different regulatory regimes, dynamically allocating tokens based on investor eligibility, and efficiently managing payouts and potential mergers of different share classes.

Use Case 3: Force Transfer for AML/KYC/Compliance Violations

In the world of tokenized securities, maintaining compliance with regulatory requirements is of utmost importance. This proposal provides a robust mechanism to handle situations where an investor's tokens need to be forcibly transferred due to violations of Anti-Money Laundering (AML), Know Your Customer (KYC), or other compliance-related regulations.

Let's consider the scenario of Alice, an investor who holds tokens in the proposed token compliant security token contract. During the regular compliance checks conducted by the token issuer or a designated compliance service, it is discovered that Alice's wallet address is associated with suspicious activities related to money laundering or other financial crimes.

In such a situation, the regulatory authorities or the contract administrators may decide to freeze Alice's account and initiate a forced transfer of her tokens to a designated address controlled by the issuer or a recovery agent. The forceTransfer function in this proposal enables this process.

Specification

---

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Interface

Methods for token

transferableBalance

Retrieves the transferable balance of tokens for the specified account and ID.

• MUST calculate and return the transferable balance of tokens for the specified account and ID (i.e. current) balanceOf(account, id) - lockedBalanceOf(account, id).

lockedBalanceOf

Retrieves the locked balance of tokens for the specified account and ID.

• MUST retrieve and return the locked balance of tokens for the specified account and id.

restrictTransfer

Restricts the transferability of tokens with the specified ID.

• MUST restrict the transferability of tokens with the specified id.
• SHOULD emit TransferRestricted.

removeRestriction

Removes the transferability restriction of tokens with the specified ID.

• MUST remove the transferability restriction of tokens with the specified id. MUST revert if id was not previously restricted.
• SHOULD emit TransferRestrictionRemoved.

safeTransferFrom

• MUST revert if _to is the zero address.
• MUST revert if balance of holder for token _id is lower than the _value sent.
• MUST revert on any other error.
• MUST emit the TransferSingle event to reflect the balance change (see "Safe Transfer Rules" section of the standard).
• MUST call canTransfer function to check if the transfer can proceed

canTransfer

Determine transferring a specified amount of a token from one address to another.

• Accurately determine whether the transfer of tokens is allowed.
• MUST validate to and from are not frozen address.
• MUST validate id of the transfer should not be restricted
• MUST check if amount is a transferable balance.
• MAY call external contract to verify the transfer.
• SHOULD NOT modify any state or perform any side effects.

lockTokens

Locks a specified amount of tokens from an account for a specified duration.

• MUST enforce time-based restrictions on the transfer or use of tokens.
• MUST revert if balance of holder is less than amount.
• SHOULD use proper access control measures to ensure that only authorized entities can lock tokens.
• MUST perform input validation prevent potential vulnerabilities and unauthorized locking of tokens.
• SHOULD record release time securely and ensure that locked tokens are only released after the designated time has passed.
• SHOULD emit TokensLocked.

unlockToken

Unlocks tokens that have crossed the release time for a specific account and id.

• MUST unlock the tokens for the specified account address and id.
• MUST unlock all the token which has release time <= block.timestamp
• SHOULD revert if no token are unlocked to save gas.
• SHOULD emit TokenUnlocked.

forceTransfer

Force transfer in cases like recovery of tokens

• MUST bypass normal transfer restrictions and authorization checks.
• MUST revert if the from address is not Frozen.
• MUST revert if to address is Frozen.
• MUST ensure that only authorized entities have the capability to call this function.
• Additional data related to the freeze operation.
• SHOULD emit TokensForceTransferred.

freeze

Freezes specified address. The Freeze function takes in the account address to be frozen and additional data, and returns a boolean value indicating whether the operation was successful.

• MUST prevent account to transfer and payout.
• SHOULD implement appropriate access control measures to ensure that only authorized addresses can be unfrozen.
• SHOULD emit AddressFrozen.

unFreeze

The Unfreeze function takes in the account address to be unfrozen and additional data, and returns a boolean value indicating whether the operation was successful.

• MUST unfreeze the specified account
• SHOULD implement appropriate access control measures to ensure that only authorized addresses can be unfrozen.
• SHOULD emit AddressUnfrozen.

payout

Send payouts to single address, receiver will be receiving a specific amount of tokens.

• MUST revert if to address is frozen address.
• SHOULD have sufficient balance to transfer token from issuer address.
• SHOULD emit PayoutDelivered.

batchPayout

Send payouts to multiple addresses at once, with each address receiving a specific amount of tokens. It can be used for various purposes such as distributing rewards, dividends, or interest payment.

• MUST revert if to address is frozen address.
• SHOULD have sufficient balance to transfer token from issuer address.
• SHOULD emit PayoutDelivered.

Interoperability

This proposal facilitates interoperability with non-fungible and fungible tokens through a token wrapping method. The process involves two key components: the token contracts representing the original and the proposed token contract for the wrapped version. Users seeking to wrap their tokens interact with the wrapping contract, which securely locks their original tokens and mints an equivalent amount of the proposed tokens to their address. Conversely, unwrapping is achieved by calling the contract's withdraw function, resulting in the burning of the proposed tokens and the release of the corresponding original tokens. Events are emitted for transparency, and robust security measures are implemented to safeguard user assets and address any potential vulnerabilities in the contract code. With this design, this proposal ensures the seamless conversion and compatibility with fungible and non-fungible tokens, promoting greater utility and usability across the Ethereum ecosystem.

Interface for Interoperability

Methods for Interoperability

setWrappedTokenAddress

• token address could be any security token standard i.e ERC-3643.

wrapToken

• MUST lock token in an on-chain vault type smart contract.
• MUST mint an equivalent amount of the proposed token.
• MUST verify mapping of ERC-1155 id with the corresponding ERC-20 compatible security token.

wrapTokenFromPartition

• MUST lock the token amount from source standard and mint an equivalent amount of the proposed token.
• SHOULD lock token in smart contract to achieve one to one mapping with the investor.
• MUST verify mapping of id with the corresponding partially fungible security token partitionId.

unwrapToken

• MUST burn the proposed token and release the original token.
• MUST verify that the token is not subject to any of the proposal's locking functionality.

Partition Management

The proposal leverages the tokenId feature of ERC-1155 to represent distinct partitions within a token contract. Each tokenId corresponds to a unique partition with its own set of rights, privileges, and compliance rules. This enables the creation of semi-fungible tokens representing fractional ownership, different share classes, or other granular units.

Partition as the Fundamental Unit

• Each partition is created by minting tokens under a unique tokenId value.
• All tokens with the same tokenId are fungible within that partition but non-fungible across partitions.
• The issuer can represent different classes, jurisdictions, or series by minting tokens under different tokenIds.

Compliance Management

This standard includes functions for managing token transfers in accordance with regulatory requirements and issuer-defined rules. The canTransfer function checks whether a transfer is allowed based on factors such as token restrictions, frozen addresses, transferable balances, and token locking.

To facilitate dynamic compliance management, the standard uses a voucher-based pattern. An authorized entity (e.g., the issuer or a designated compliance service) generates a signed off-chain voucher that may encapsulate results from on-chain rule evaluation, oracle responses, or other checks. The canTransfer verifies vouchers signature, expiry, and binding of from, to, id, and amount together with contract state to determine the eligibility of a transfer.

Here's an example of how off-chain vouchers can be used with the proposal:

1. The token issuer defines a set of compliance rules and requirements for token transfers.
2. When a user initiates a transfer, they submit a request to a designated compliance service with the necessary details (sender, recipient, amount, etc.).
3. The compliance service evaluates the transfer request against the predefined rules and requirements, considering factors such as investor eligibility, transfer restrictions, and regulatory compliance.
4. If the transfer is deemed compliant, the compliance service generates a signed voucher containing the relevant details and returns it to the user.
5. The user includes the signed voucher as an additional parameter when calling the safeTransferFrom function on the proposed contract.
6. The canTransfer function verifies the authenticity and validity of the voucher by checking the signature and ensuring that the voucher details match the transfer parameters.
7. If the voucher is valid and the transfer meets all other requirements, the transfer is allowed to proceed.

Implementations MAY accept a cryptographically signed compliance voucher in the data argument of canTransfer, and state changing transfer functions defined in this standard, for example safeTransferFrom. Voucher schema and policy content are application defined. Implementations MAY combine on chain rules, oracle responses, and off chain verification for the voucher.

Token Recovery

In case of lost or compromised wallets, the proposal includes a forceTransfer function that allows authorized entities (e.g., the issuer or a designated recovery agent) to transfer tokens from one address to another. This function bypasses the usual transfer restrictions and can be used as a recovery mechanism.

Payout Management

Provides functions for efficient payout distribution to token holders. The payout function allows sending payouts to a single address, while batchPayout enables sending payouts to multiple addresses in a single transaction. These functions streamline the process of distributing dividends, interest, or other payments to token holders.

Rationale

---

Enhancing Compliance Management

The canTransfer function facilitates compliance checks during token transfers, offering adaptability through diverse implementation methods such as on-chain storage, oracle utilization, or any off-chain methodologies. This versatility ensures seamless integration with existing compliance frameworks, particularly in enforcing regulatory standards like KYC/AML. Additionally, functionalities like freezeAddress, restrictTransfer, lockToken and forceTransfer empower entities to regulate token movements based on specified conditions or regulatory requirements. Complementing these, the unlockToken function enhances transparency and accountability by facilitating the release of tokens post-compliance actions.

Fractionalization

Fractionalization in this standard is realized natively through ERC-1155 balances. For a given partition identified by tokenId, each unit of amount represents a fungible fraction of that partition’s underlying security. Issuers mint and burn units to manage supply. Transfers use safeTransferFrom and safeBatchTransferFrom, and must pass canTransfer. Locks and freezes reduce the transferable portion of balances, and forceTransfer operates proportionally on units. Partitions can be merged by issuing a new tokenId and allowing holders to deposit old partitions for one-to-one or proportional conversion, and can be split by minting new tokenIds with defined conversion rules. All compliance rules and restrictions apply identically to every fractional unit in a partition.

Interoperability with other standard

This standard builds directly on ERC-1155, which already models fractional supply, batching, and balance-based accounting with broad ecosystem support. ERC-3525 was carefully evaluated but intentionally not adopted as a base. Its slot-and-value abstraction overlaps almost exactly with the partition and amount semantics defined here, yet inherits ERC-721’s single-token overhead and per-position statefulness, which are inefficient for large scale issuance and compliance checks. Implementers who require slot-style compatibility may optionally expose ERC-3525 through ERC-165 by mapping slot to partition and value to amount. ERC-6909, while a minimal multi-token variant, omits partition metadata and compliance hooks and is therefore unsuitable for regulated assets. ERC-7518 extends this lineage by representing partitions as ERC-1155 tokenIds, enabling dynamic minting, merging, and voucher based dynamic compliance that can evolve without redeployment. Overall, ERC-7518 uses ERC-1155 as its canonical substrate because it balances composability, efficiency, and regulatory flexibility, turning fractionalization into a compliance-preserving primitive rather than an auxiliary layer.

The functions wrapToken and wrapTokenFromPartition are essential for simplifying conversions within the token system. wrapToken is specifically designed for wrapping ERC-20-like tokens to this protocol, on the other hand, wrapTokenFromPartition is used when we want to convert tokens from non-fungible tokens or any multi-standard token into proposed protocol. It allows for more specialized conversions, ensuring tokens from different standards can work together smoothly.

The unwrapToken function is used to reverse the process of wrapping tokens. When tokens are wrapped, they're usually locked or held in a special way to ensure they're used correctly. users can unlock or release these tokens, returning them to their original standard, essentially, frees up tokens that were previously locked, giving users more control over their assets in the ecosystem.

Payment distribution

The payout function enables direct payments to individual token holders for one-off or event-triggered distributions, facilitating targeted disbursements. Meanwhile, the batchPayout function processes multiple payments in a single transaction, optimizing efficiency for larger-scale or regular payouts on the blockchain

Backwards Compatibility

---

The proposal is fully compatible with ERC-1155 , and any ERC-1155 compliant wallet or marketplace can interact with the proposal's tokens. The additional functions introduced by this proposal do not conflict with the ERC-1155 interface, ensuring seamless integration with existing ecosystem tools and infrastructure.

Security Considerations

---

1. Access Control: The proposal includes functions that can significantly impact token transfers and balances, such as forceTransfer, freezeAddress, and lockTokens. It is crucial to implement proper access control mechanisms, such as role-based permissions, to ensure that only authorized entities can execute these functions.
2. Parameter Validation: Functions like safeTransferFrom, lockTokens, and forceTransfer should validate input parameters to prevent unauthorized or unintended actions. This includes checking for valid addresses, sufficient balances, and appropriate permissions.
3. Reentrancy Protection: The contract should implement reentrancy guards to prevent potential vulnerabilities arising from external calls, especially in functions that transfer tokens or update balances.
4. Overflow/Underflow Protection: The contract should use safe math libraries or built-in overflow protection to prevent integer overflow and underflow vulnerabilities.
5. Payout Security: The payout and batchPayout functions should ensure that only authorized entities can initiate payouts and that the total payout amount does not exceed the available balance. Proper access control and input validation are essential to prevent unauthorized or fraudulent payouts.
6. Off-Chain Voucher Security: When using off-chain vouchers for dynamic compliance management, it is crucial to ensure the security and integrity of the voucher generation process. The compliance service responsible for generating vouchers should have robust security measures in place to prevent unauthorized voucher creation or tampering. Additionally, the proposed contract should thoroughly validate the authenticity and validity of vouchers before allowing transfers to proceed.
7. Operational considerations for unfreezing: Unfreezing restores an account's ability to transfer and receive payouts. Implementers and operators should evaluate applicable regulatory and contractual obligations before unfreezing an address.

Copyright

---

Copyright and related rights waived via CC0.