TL;DR
True innovation in tokenized capital markets is only possible through regulatory compliance. Our new security token standard based on RCP (Regulatory Compliance Protocol) overcomes the limitations of existing ERC standards by integrating traceability at the protocol core.
- System-wide AML: Moving beyond simple transaction tracking to integrated identity management at the protocol level
- OCID System: The first oracle-native identity management structure spanning on-chain, off-chain, and cross-chain environments
- Legal Completeness: Achieving complete audit trails and transparency required by regulatory authorities
At the intersection where global financial markets meet blockchain technology, we face a startling reality. According to the Financial Action Task Force (FATF) 2024 report, 75% of 130 jurisdictions are only partially compliant or non-compliant with virtual asset regulations. However, security token standards proposed to date have failed to fully meet this fundamental requirement. While existing standards like ERC-1400 and ERC-3643 offered partial solutions, the comprehensive traceability required in true state synchronization environments remained an unfinished challenge.
Our proposed RCP-based security token standard establishes Traceability as the first regulatory pillar to overcome these limitations. This means complete auditability in oracle state synchronization environments, going beyond simple transaction records.
Limitations of Existing Standards
ERC-1400’s Restrictive Approach
ERC-1400 was a pioneering attempt for security tokens, but shows fundamental limitations in traceability aspects. While it provides token partitioning through partition systems and document management, it lacks the comprehensive tracking mechanisms actually required by regulatory authorities.
// ERC-1400's limited tracking functionality
interface IERC1400 {
function getDocument(bytes32 _name) external view returns (string memory, bytes32, uint256);
function setDocument(bytes32 _name, string calldata _uri, bytes32 _documentHash) external;
}
This approach is limited to static document linking and fails to provide audit trails that encompass dynamic state changes and cross-chain interactions.
ERC-3643’s Partial Progress and Limitations
ERC-3643 made progress in identity verification through ONCHAIN ID, but still couldn’t escape single-chain-centric thinking. Moreover, it doesn’t support the off-chain to on-chain integrated tracking required in state synchronization environments.
“Existing security token standards focus only on traditional transaction tracking, falling short of the complete transparency required by oracle state synchronization.”– Oraclizer Core Team Research Report
RCP-based Traceability Architecture
Oracle Contract ID (OCID) System
The core of our proposed new standard is the OCID (Oracle Contract ID) System. This is the first identity management system in blockchain oracle technology, featuring the following innovative characteristics:
struct OCID {
string damlPartyId; // DAML contract participant identifier
string zkId; // Zero-knowledge proof-based privacy identity
bytes32 contractHash; // Unique hash for specific contract
uint256 createdAt; // Creation timestamp
bool isActive; // Active status
}
mapping(bytes32 => OCID) private ocidRegistry;
mapping(address => bytes32[]) private userOCIDs;
Key Reference Note: OCID is newly generated for each oracle contract and can be infinitely created up to the number of contracts, serving as a pseudonymous ID that makes participants’ identities traceable while preserving privacy.
System-wide AML Implementation
contract RCPTraceable {
struct TransactionTrace {
bytes32 fromOCID;
bytes32 toOCID;
uint256 amount;
bytes32 assetClass;
uint256 timestamp;
bytes32 sourceChainId;
bytes32 regulatoryFlags;
bytes32 parentTxHash; // Related transaction tracking
}
mapping(bytes32 => TransactionTrace) public transactionRegistry;
mapping(bytes32 => bytes32[]) public ocidTransactionHistory;
event StateTransitionLogged(
bytes32 indexed txHash,
bytes32 indexed fromOCID,
bytes32 indexed toOCID,
uint256 amount,
bytes32 regulatoryContext
);
function logStateTransition(
bytes32 _fromOCID,
bytes32 _toOCID,
uint256 _amount,
bytes32 _assetClass,
bytes32 _regulatoryContext
) internal {
bytes32 txHash = keccak256(
abi.encodePacked(
_fromOCID, _toOCID, _amount,
block.timestamp, block.chainid
)
);
transactionRegistry[txHash] = TransactionTrace({
fromOCID: _fromOCID,
toOCID: _toOCID,
amount: _amount,
assetClass: _assetClass,
timestamp: block.timestamp,
sourceChainId: bytes32(block.chainid),
regulatoryFlags: _regulatoryContext,
parentTxHash: _getParentTransaction()
});
// Bidirectional transaction history update
ocidTransactionHistory[_fromOCID].push(txHash);
ocidTransactionHistory[_toOCID].push(txHash);
emit StateTransitionLogged(txHash, _fromOCID, _toOCID, _amount, _regulatoryContext);
}
}
This structure enables integrated AML tracking at the protocol level. All transactions are tracked through OCID, ensuring consistent identity management even in cross-chain environments.
Cross-chain Traceability Innovation
ERC-3770 Integrated Address System
contract CrossChainTraceability {
struct ChainedAssetState {
string erc3770Address; // chainId:address format
bytes32 currentOCID;
bytes32 lastStateHash;
uint256 lastUpdateBlock;
mapping(uint256 => bytes32) stateHistory;
}
mapping(bytes32 => ChainedAssetState) public assetStates;
mapping(bytes32 => bytes32[]) public crossChainTransactionPath;
function updateCrossChainState(
bytes32 _assetId,
string memory _targetChainAddress,
bytes32 _newOCID,
bytes32 _stateProof
) external onlyAuthorizedOracle {
ChainedAssetState storage asset = assetStates[_assetId];
// Record state change
asset.stateHistory[block.number] = asset.lastStateHash;
asset.lastStateHash = keccak256(
abi.encodePacked(_targetChainAddress, _newOCID, _stateProof)
);
// Track cross-chain path
crossChainTransactionPath[_assetId].push(asset.lastStateHash);
emit CrossChainStateUpdate(_assetId, _targetChainAddress, _newOCID);
}
}
Off-chain to On-chain Integrated Audit Trail
The biggest challenge we faced was the complete connection between off-chain state and on-chain state. To solve this, we designed the following integrated audit system:
interface IOffChainAuditBridge {
struct OffChainStateProof {
bytes32 externalSystemId; // CANTON, external DLT, etc.
bytes32 externalTransactionId;
bytes32 stateRoot;
bytes zkProof; // Zero-knowledge state proof
uint256 timestamp;
bytes regulatoryAttestation; // Regulatory authority proof
}
function bridgeOffChainState(
bytes32 _assetId,
OffChainStateProof memory _proof
) external;
function getCompleteAuditTrail(
bytes32 _assetId
) external view returns (
bytes32[] memory onChainStates,
OffChainStateProof[] memory offChainStates
);
}
Regulatory Audit Interface
Compliance Monitoring
contract RegulatoryAuditInterface {
mapping(address => bool) public authorizedRegulators;
mapping(bytes32 => uint256) public auditAccessLevel;
modifier onlyRegulator() {
require(authorizedRegulators[msg.sender], "Unauthorized regulator");
_;
}
function getCompleteTransactionHistory(
bytes32 _ocid,
uint256 _fromBlock,
uint256 _toBlock
) external view onlyRegulator returns (
TransactionTrace[] memory transactions,
OffChainStateProof[] memory offChainProofs,
bytes32[] memory regulatoryFlags
) {
// Return comprehensive transaction history
// Provide on-chain to off-chain integrated audit trail
}
function flagSuspiciousActivity(
bytes32 _transactionHash,
bytes32 _flagReason,
bytes memory _evidence
) external onlyRegulator {
// Flag suspicious activity
// Trigger automatic alerts and additional monitoring
}
}
Important Information: Regulatory authorities can set up monitoring for specific assets or OCIDs as needed, and automatically receive alerts when suspicious patterns are detected. This enables proactive compliance monitoring that was impossible with existing security token standards.
Balancing Privacy and Transparency
Zero-Knowledge Proof-based Selective Disclosure
Just because traceability means transparency doesn’t mean privacy must be sacrificed. Our standard harmonizes these two requirements using zero-knowledge proofs:
contract ZKPrivacyLayer {
struct SelectiveDisclosure {
bytes32 dataHash;
bytes zkProof; // Data existence proof
uint256 accessLevel; // Disclosure level (0: fully private, 100: fully public)
mapping(address => bool) authorizedViewers;
}
mapping(bytes32 => SelectiveDisclosure) private disclosureRegistry;
function proveDataExistence(
bytes32 _dataHash,
bytes memory _zkProof
) external view returns (bool) {
// Prove data existence without revealing content
return verifyZKProof(_zkProof, _dataHash);
}
function authorizeDataAccess(
bytes32 _dataHash,
address _regulator,
uint256 _accessLevel
) external onlyDataOwner {
// Grant selective data access to regulatory authorities
disclosureRegistry[_dataHash].authorizedViewers[_regulator] = true;
}
}
Need-to-Know Basis Implementation
Tip: When implementing the need-to-know basis principle, it’s important to segment accessible information according to each participant’s role. For example, auditors can access transaction amounts and timing but not personal information of transaction parties. For detailed implementation methods, refer to the FATF AML Guidelines.
Anomaly Detection System
Pattern-based Monitoring
contract AnomalyDetection {
struct TransactionPattern {
uint256 averageAmount;
uint256 frequency;
uint256 timeWindow;
bytes32[] commonCounterparties;
}
mapping(bytes32 => TransactionPattern) private ocidPatterns;
mapping(bytes32 => uint256) private anomalyScores;
function analyzeTransaction(
bytes32 _fromOCID,
bytes32 _toOCID,
uint256 _amount,
bytes32 _assetClass
) internal returns (uint256 anomalyScore) {
TransactionPattern memory fromPattern = ocidPatterns[_fromOCID];
// Amount anomaly detection
if (_amount > fromPattern.averageAmount * 10) {
anomalyScore += 30;
}
// Frequency anomaly detection
uint256 recentTxCount = _getRecentTransactionCount(_fromOCID, 1 hours);
if (recentTxCount > fromPattern.frequency * 5) {
anomalyScore += 40;
}
// New counterparty detection
if (!_isKnownCounterparty(_fromOCID, _toOCID)) {
anomalyScore += 20;
}
if (anomalyScore > 70) {
emit SuspiciousActivityDetected(_fromOCID, _toOCID, _amount, anomalyScore);
_triggerComplianceReview(_fromOCID, _toOCID, anomalyScore);
}
return anomalyScore;
}
}
Technical Implementation Innovation
The most innovative aspect of our proposed traceability system is its design optimized for state synchronization environments. While existing standards focused only on static on-chain transactions, our approach enables complete tracking of off-chain to on-chain state changes.
“Complete traceability means not just recording ‘who did what when,’ but encompassing ‘why that state change occurred’ and ‘its impact on the entire system.'”
This philosophy is reflected in all our technical choices. The OCID system, cross-chain state tracking, and zero-knowledge proof-based privacy protection are all part of an integrated approach to achieve this goal.
Future Scalability and Interoperability
Modular Compliance Framework
interface IComplianceModule {
function validateTransaction(
bytes32 _fromOCID,
bytes32 _toOCID,
uint256 _amount,
bytes32 _assetClass,
bytes memory _metadata
) external view returns (bool isCompliant, bytes memory reason);
function getRequiredDocumentation(
bytes32 _transactionType
) external view returns (bytes32[] memory documentHashes);
}
contract ModularComplianceFramework {
mapping(bytes32 => address) public complianceModules;
mapping(bytes32 => bool) public moduleActiveStatus;
function addComplianceModule(
bytes32 _jurisdictionId,
address _moduleAddress
) external onlyGovernance {
complianceModules[_jurisdictionId] = _moduleAddress;
moduleActiveStatus[_jurisdictionId] = true;
}
function validateMultiJurisdictionCompliance(
bytes32[] memory _jurisdictions,
TransactionData memory _txData
) external view returns (bool[] memory complianceResults) {
complianceResults = new bool[](_jurisdictions.length);
for (uint256 i = 0; i < _jurisdictions.length; i++) {
if (moduleActiveStatus[_jurisdictions[i]]) {
(bool isCompliant,) = IComplianceModule(
complianceModules[_jurisdictions[i]]
).validateTransaction(
_txData.fromOCID,
_txData.toOCID,
_txData.amount,
_txData.assetClass,
_txData.metadata
);
complianceResults[i] = isCompliant;
}
}
}
}
Traceability is not just a feature, but the foundation of existence for tokenized capital markets. Without regulatory trust, no innovative technology can enter large-scale capital markets, and this trust can only be built through complete and transparent tracking systems.
Our RCP-based security token standard’s traceability implementation presents a new paradigm that simultaneously achieves technological innovation and regulatory compliance based on this recognition. This will be the first implementation of the comprehensive transparency required by the new thesis of oracle state synchronization.
In our next article, we will explore RCP’s second pillar, ‘Confidentiality,’ and deeply examine how transparency and privacy can be harmonized.
References
[1]. Tokeny Solutions. (2023). ERC-3643 – The Official Smart Contract Standard for Permissioned Tokens. https://tokeny.com/erc3643/
[2]. Financial Action Task Force. (2021). Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html
[3]. Chainalysis. (2025). Introduction to ERC-3643 Tokens. https://www.chainalysis.com/blog/introduction-to-erc-3643-ethereum-rwa-token-standard/
[4]. Financial Crime Academy. (2025). Revolutionizing AML Compliance: AML Monitoring On Blockchain Explained. https://financialcrimeacademy.org/aml-monitoring-on-blockchain/
[5]. Polymath Network. ERC-1400: The Security Token Standard. https://www.polymath.network/erc-1400
