Cross-Chain Asset Bridge

IOST 3.0 leverage this bridge to attract liquidity and increase trading volume by building products similar to STRIPs

1. Project Background & Design Motivation

With the rapid growth of Real-World Asset (RWA) tokenization, assets on different chains are often fragmented and managed under different standards. To achieve unified asset management and boost liquidity, our system maps external RWA assets (e.g., from BSC and Ethereum) into our BSC L2 platform. In our design, we use a cross-chain bridge module to lock external assets and generate a "mapping proof." This proof is then used to standardize the asset via our tokenization engine (which issues BEP-20 tokens) and immediately split it into two parts:

• Principal Token: Represents the core asset value and is designed for risk-averse investors.
• Interest Token: Represents future earnings (such as interest, coupons, or rental income) and is intended for investors seeking higher returns.

To ensure security and compliance, we introduce the compliance module early in the process—right after asset mapping and before tokenization. This ensures that both the asset source and the participants are verified (via KYC/KYB and DID) before they enter subsequent processing.

2. System Architecture Overview & Workflow

Our system is composed of the following core modules:

Cross-Chain Bridge Module

• Function: Monitors external-chain RWA assets, locks/stakes these assets, and generates a mapping proof.
• Role: Ensures the asset’s state is immutable during the mapping process and provides a trusted proof for subsequent tokenization.

Compliance Module (KYC/KYB/DID Verification)

• Function: Validates the asset source and participant identity before proceeding with tokenization.
• Role: Ensures all assets and users meet regulatory requirements, providing a secure and compliant foundation.

Tokenization Engine

• Function: Receives the mapping proof along with verified asset metadata and generates standardized asset tokens in BEP-20 format.
• Role: Unifies assets from various chains under one standard and supplies the basis for principal/interest separation.

Principal/Interest Separation Module

• Function: Automatically splits the tokenized asset into two tokens: the Principal Token and the Interest Token.
• Role: Offers products with different risk/return profiles to cater to diverse investor needs and stimulate secondary market activity.

Liquidity & Matching Module

• Function: Manages separate liquidity pools for Principal and Interest tokens and provides order matching services.
• Role: Ensures proper price discovery, market depth, and efficient trading.

Workflow Summary

• External Asset Locking: External-chain RWA assets are first locked by the Cross-Chain Bridge, which generates a mapping proof.
• Compliance Verification: The mapping proof and asset details are then forwarded to the Compliance Module for KYC/KYB/DID verification.
• Asset Tokenization: Once verified, the Tokenization Engine uses the mapping proof and asset metadata to create standardized BEP-20 tokens.
• Principal/Interest Separation: The asset is then split into two tokens: the Principal Token and the Interest Token (with built-in interest accrual and settlement logic).
• Liquidity & Trading: Finally, the separated tokens enter dedicated liquidity pools and the Matching Module supports secondary market trading and settlement.

3. System Architecture Diagram

How it works:

• External assets are locked by the Bridge, which produces a mapping proof.
• The mapping proof and asset data are verified in the Compliance Module.
• The Tokenization Engine standardizes the asset (BEP-20 format).
• The asset is split into Principal and Interest tokens.
• The tokens enter liquidity pools and are traded in the secondary market.

4. Core Contract Definitions (class definitions)

Cross-Chain Bridge Module

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/**
 * @title CrossChainBridge
 * @dev Locks external-chain assets and generates a mapping proof.
 */
contract CrossChainBridge {
    mapping(string => bytes) public lockedAssets;

    /**
     * @notice Locks an external asset.
     * @param assetId The unique identifier of the external asset.
     * @param assetMetadata The asset's detailed information (e.g., value, type, chain ID).
     * @return Returns the assetId used for locking.
     */
    function lockAsset(string memory assetId, bytes memory assetMetadata) public returns (string memory) {
        lockedAssets[assetId] = assetMetadata;
        return assetId;
    }

    /**
     * @notice Generates a mapping proof for the locked asset.
     * @param lockedAssetId The identifier of the locked asset.
     * @return A mapping proof string, e.g., "Proof_of_assetId".
     */
    function generateMappingProof(string memory lockedAssetId) public view returns (string memory) {
        return string(abi.encodePacked("Proof_of_", lockedAssetId));
    }
}

Compliance Module

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/**
 * @title ComplianceModule
 * @dev Performs lightweight KYC/KYB and DID verification for users and assets.
 */
contract ComplianceModule {
    mapping(address => bool) public verifiedUsers;

    event UserVerified(address user);

    /**
     * @notice Verifies a user's compliance using KYC/KYB data.
     * @param user The user's address.
     * @param kycData Encrypted KYC/KYB documentation.
     * @return Returns true if verification passes.
     */
    function verifyUser(address user, bytes memory kycData) public returns (bool) {
        // Implement KYC/KYB verification logic here.
        verifiedUsers[user] = true;
        emit UserVerified(user);
        return true;
    }

    /**
     * @notice Checks whether a user has been verified.
     * @param user The user's address.
     * @return True if the user is verified.
     */
    function isVerified(address user) public view returns (bool) {
        return verifiedUsers[user];
    }
}

Tokenization & Principal/Interest Separation Module

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/**
 * @title TokenizationEngine
 * @dev Generates standardized BEP-20 asset tokens from a mapping proof and asset metadata, then performs principal/interest separation.
 */
contract TokenizationEngine {
    event AssetTokenized(string assetId, string principalTokenId, string interestTokenId);

    /**
     * @notice Tokenizes an asset and splits it into Principal and Interest tokens.
     * @param mappingProof The mapping proof string.
     * @param assetId The asset's unique identifier.
     * @param principalValue The principal value of the asset.
     * @param interestRate The interest rate or yield ratio.
     * @return principalTokenId The identifier for the Principal Token.
     * @return interestTokenId The identifier for the Interest Token.
     */
    function tokenizeAsset(
        string memory mappingProof,
        string memory assetId,
        uint256 principalValue,
        uint256 interestRate
    ) public returns (string memory, string memory) {
        // Assuming compliance verification has been completed.
        string memory principalTokenId = string(abi.encodePacked("P-", assetId));
        string memory interestTokenId = string(abi.encodePacked("I-", assetId));
        emit AssetTokenized(assetId, principalTokenId, interestTokenId);
        return (principalTokenId, interestTokenId);
    }
}

NOTE

In a full implementation, the Principal and Interest tokens would be deployed as BEP-20 compliant contracts, ensuring compatibility with our BSC L2 platform.

Liquidity & Matching Module (Overview)

This module manages separate liquidity pools for the two token types and facilitates order matching. Detailed implementation is based on industry-standard decentralized exchange (DEX) designs. Core functions include adding/removing liquidity, order submission, and matching.

5. Compliance & Security Considerations

By integrating the Compliance Module before the asset tokenization step, we ensure that:

• User Identity Verification: Only verified users (meeting KYC/KYB requirements) can participate, mitigating risks such as money laundering and fraud.
• Asset Qualification Check: External assets are verified against regulatory data to ensure legitimacy.
• DID Integration: Decentralized identity solutions protect user privacy while maintaining data trustworthiness. This front-loading of compliance verification not only enhances system security but also provides a robust foundation for subsequent tokenization, principal/interest separation, and market trading.

6. What's next

Currently our system splits each asset into two distinct tokens—one representing the principal value and the other representing future earnings. Integrated liquidity management and order matching further enable efficient secondary market trading while ensuring full regulatory compliance. In the next step, our team is dedicated to propose 3 new BEP types and use native BEP token to increase interoperability.