Privacy: The Second Pillar of NEW-EIP

TL;DR

Privacy in regulated financial systems isn’t about complete anonymity, but rather selective transparency that protects sensitive information while enabling regulatory oversight. Our NEW-EIP introduces a three-layer privacy architecture that balances these competing needs through zero-knowledge proofs and role-based access controls. This approach transforms traditional binary privacy models into a nuanced framework where information disclosure is proportional to regulatory requirements. The implementation includes code patterns for on-chain identity abstraction and privacy-preserving verification mechanisms that maintain regulatory compliance without sacrificing individual privacy.

---

In the world of blockchain and decentralized finance, privacy and regulatory compliance have often been positioned as opposing forces. The open, transparent nature of public blockchains seems fundamentally at odds with the confidentiality requirements of traditional financial systems. Yet, as we’ve explored in our development of the Regulatory Compliance Protocol (RCP), this dichotomy is not inevitable but rather a design choice—one that we can reimagine through thoughtful architectural decisions.

The challenge before us is not merely technical but philosophical: How do we create systems that protect sensitive financial information while simultaneously providing regulators with the visibility they need to enforce rules and protect market integrity? This question lies at the heart of our second pillar of NEW-EIP—Privacy.

The Privacy Paradox in Financial Systems

Traditional financial systems operate on a “trust the institution” model, where banks and financial entities collect vast amounts of personal and transaction data, protecting it through internal controls while providing access to regulators when required. This model centralizes both privacy protection and regulatory oversight.

Blockchain technology disrupted this paradigm by creating transparent, immutable ledgers where transaction history is publicly visible. This approach solved the problem of trust but created new privacy challenges—especially for regulated financial assets.

“Privacy is not about hiding something, but about protecting something.” – this principle guided our development of privacy mechanisms in the NEW-EIP standard.

The core insight that emerged from our research is that privacy isn’t binary—it exists on a spectrum that can be calibrated according to specific regulatory contexts and user needs. This realization led us to develop what we call “context-aware privacy” as the foundation of our approach.

Three-Layer Privacy Architecture

After multiple iterations and extensive consultation with both privacy advocates and regulatory experts, we developed a three-layer privacy architecture that forms the foundation of our NEW-EIP privacy implementation.

Each layer serves a distinct purpose in the privacy-compliance ecosystem:

Layer 1: Public Compliance Layer

This outermost layer exposes only the minimum information necessary for basic compliance verification. It makes publicly visible:

• Compliance Status: Boolean values or simple status codes indicating whether an asset complies with relevant regulations
• Asset Type: The classification of the financial instrument (e.g., bond, equity, derivative)
• Jurisdiction: The regulatory framework governing the asset
• Risk Score Hash: A hash of more detailed risk assessments without revealing the underlying data

This layer allows any observer to verify that an asset exists within a compliant framework without accessing sensitive details about the asset or its holders.

// Example implementation of Public Compliance Layer
struct ComplianceStatus {
    bool isCompliant;
    bytes32 assetTypeId;
    bytes32 jurisdictionId;
    bytes32 riskScoreHash;
}

mapping(bytes32 => ComplianceStatus) public assetComplianceRegistry;

function verifyCompliance(bytes32 assetId) public view returns (bool) {
    return assetComplianceRegistry[assetId].isCompliant;
}

Layer 2: Selective Disclosure Layer

The middle layer implements the principle of selective transparency, where information is accessible based on the requestor’s role and regulatory authority:

• ZK Identity Proofs: Zero-knowledge proofs that verify the holder’s eligibility without revealing identity
• Encrypted Attributes: Asset and holder attributes encrypted with keys specific to authorized parties
• Role-Based Access: Granular controls determining which regulatory entities can access what information

This layer is where our most significant innovations lie, as it enables fine-tuned information sharing based on regulatory requirements.

// Example implementation of Selective Disclosure Layer
struct SelectiveDisclosure {
    mapping(address => bool) authorizedRegulators;
    mapping(bytes4 => mapping(address => bool)) attributeAccess;
    mapping(bytes4 => bytes) encryptedAttributes;
}

mapping(bytes32 => SelectiveDisclosure) private assetDisclosureControls;

function grantAccess(
    bytes32 assetId,
    address regulator,
    bytes4[] memory attributeSelectors
) external onlyAssetIssuer(assetId) {
    SelectiveDisclosure storage disclosure = assetDisclosureControls[assetId];
    disclosure.authorizedRegulators[regulator] = true;

    for (uint i = 0; i < attributeSelectors.length; i++) {
        disclosure.attributeAccess[attributeSelectors[i]][regulator] = true;
    }
}

function getAttributeIfAuthorized(
    bytes32 assetId,
    bytes4 attributeSelector
) external view returns (bytes memory) {
    require(assetDisclosureControls[assetId].authorizedRegulators[msg.sender], 
            "Not authorized");
    require(assetDisclosureControls[assetId].attributeAccess[attributeSelector][msg.sender], 
            "No access to this attribute");

    return assetDisclosureControls[assetId].encryptedAttributes[attributeSelector];
}

Layer 3: Private Data Layer

The innermost layer contains the most sensitive information that is never stored directly on-chain:

• Personal Details: Personally identifiable information of asset holders
• Transaction History: Detailed record of transactions
• Financial Positions: Specific holdings and exposure
• Raw KYC: Original know-your-customer documentation

This data is stored off-chain in secure, encrypted repositories with cryptographic links to on-chain assets.

// Example reference to off-chain private data
struct PrivateDataReference {
    bytes32 dataHash;          // Hash of the encrypted off-chain data
    address storageProvider;   // Entity responsible for secure storage
    bytes encryptionPublicKey; // Public key for encrypting communications
    uint256 lastUpdated;       // Timestamp of last update
}

mapping(bytes32 => mapping(address => PrivateDataReference)) private confidentialData;

// Only emits an event with encrypted parameters that authorized parties can decrypt
function updatePrivateData(
    bytes32 assetId,
    bytes32 newDataHash,
    bytes calldata encryptedUpdateDetails
) external onlyAuthorized {
    PrivateDataReference storage ref = confidentialData[assetId][msg.sender];
    ref.dataHash = newDataHash;
    ref.lastUpdated = block.timestamp;

    emit PrivateDataUpdated(assetId, msg.sender, encryptedUpdateDetails);
}

Privacy-Compliance Convergence Matrix

One of our key insights during the development of NEW-EIP was recognizing that different financial contexts require different privacy-compliance balances. We mapped these requirements into what we call the “Privacy-Compliance Convergence Matrix.”

This matrix helps token issuers and regulatory designers identify the appropriate privacy model for their specific use case. It illustrates how different financial contexts—from personal wallets to government securities—require different balances of privacy and compliance.

For example, the matrix shows that:

• Personal wallets operate in a high-privacy, low-compliance requirement zone, suitable for zero-knowledge proof mechanisms
• Corporate bonds require medium privacy with high compliance requirements, where the selective disclosure model works effectively
• Banking transactions operate in a low-privacy, high-compliance zone where traditional disclosure models are appropriate

The matrix serves not just as a theoretical framework but as a practical tool for implementation decisions in the NEW-EIP standard.

From OCID to Regulated Asset Identity (RAI)

In our earlier development stages, we conceived the Oracle Contract ID (OCID) as a mechanism for identity management within the Oraclizer ecosystem. However, as we’ve developed the NEW-EIP standard, we recognized the need for a more universal construct that can be adopted across various implementations.

We propose the Regulated Asset Identity (RAI) as a standardized mechanism for privacy-preserving identity in regulated token systems. RAI provides similar functionality to our original OCID concept but with broader applicability:

// Regulated Asset Identity (RAI) implementation
struct RAI {
    bytes32 identityCommitment; // Zero-knowledge commitment to identity
    bytes32 jurisdictionId;     // Regulatory jurisdiction
    uint256 privacyLevel;       // 0-3 corresponding to privacy layers
    mapping(bytes4 => bool) permissions; // Function selector permissions
}

mapping(address => RAI) private identities;
mapping(bytes32 => address) private identityRegistry;

// Privacy-preserving verification using zero-knowledge proofs
function verifyIdentity(
    bytes32 identityHash,
    bytes calldata zkProof,
    bytes32 verificationContext
) external view returns (bool) {
    address identityAddress = identityRegistry[identityHash];
    require(identityAddress != address(0), "Identity not registered");

    // Verify the zero-knowledge proof without revealing the underlying identity
    return ZKVerifier.verify(
        identities[identityAddress].identityCommitment,
        zkProof,
        verificationContext
    );
}

This approach allows for pseudonymous identity that can be verified by regulatory authorities when necessary, without exposing personal information on-chain.

Technical Implementation Challenges

Implementing privacy in a regulatory-compliant manner presented several technical challenges that required innovative solutions:

Challenge 1: On-chain Identity Abstraction

Traditional KYC-based systems typically store identity information directly, creating privacy risks. Our approach abstracts identity through zero-knowledge commitments:

// Creating a privacy-preserving identity commitment
function registerIdentity(
    bytes32 identityCommitment,
    bytes32 jurisdictionId,
    uint256 privacyLevel,
    bytes calldata zkProofOfValidKYC
) external {
    // Verify that the commitment corresponds to a valid KYC
    // without revealing the underlying KYC data
    require(
        KYCVerifier.verifyProof(identityCommitment, zkProofOfValidKYC),
        "Invalid KYC proof"
    );

    // Register the privacy-preserving identity
    bytes32 identityHash = keccak256(abi.encode(
        identityCommitment,
        jurisdictionId,
        privacyLevel
    ));

    identities[msg.sender] = RAI({
        identityCommitment: identityCommitment,
        jurisdictionId: jurisdictionId,
        privacyLevel: privacyLevel
    });

    identityRegistry[identityHash] = msg.sender;

    emit IdentityRegistered(identityHash, jurisdictionId, privacyLevel);
}

Challenge 2: Regulatory Access Control

Providing regulators with appropriate access without compromising the entire system required a nuanced approach:

// Selective disclosure mechanism for regulatory access
contract RegulatoryAccessControl {
    // Mapping of regulator addresses to their jurisdiction authorities
    mapping(address => bytes32) public regulatorJurisdictions;

    // Grant regulatory access to specific attributes
    function grantRegulatoryAccess(
        bytes32 assetId,
        address regulator,
        bytes4[] calldata attributeSelectors
    ) external onlyGovernance {
        require(regulatorJurisdictions[regulator] != bytes32(0), 
                "Not a recognized regulator");

        bytes32 jurisdictionId = assets[assetId].jurisdictionId;
        require(regulatorJurisdictions[regulator] == jurisdictionId, 
                "Regulator not authorized for this jurisdiction");

        for (uint i = 0; i < attributeSelectors.length; i++) {
            regulatoryAccess[assetId][regulator][attributeSelectors[i]] = true;
        }

        emit RegulatoryAccessGranted(assetId, regulator, attributeSelectors);
    }
}

Challenge 3: Cross-Jurisdictional Privacy

Different jurisdictions have different privacy requirements, creating complexities for global assets:

// Cross-jurisdictional privacy handler
function applyJurisdictionalPrivacyRules(
    bytes32 assetId,
    bytes32 fromJurisdiction,
    bytes32 toJurisdiction
) internal returns (uint256 resultingPrivacyLevel) {
    uint256 fromPrivacyLevel = jurisdictionPrivacyLevels[fromJurisdiction];
    uint256 toPrivacyLevel = jurisdictionPrivacyLevels[toJurisdiction];

    // Apply the more restrictive privacy level
    resultingPrivacyLevel = fromPrivacyLevel < toPrivacyLevel ? 
                            fromPrivacyLevel : toPrivacyLevel;

    // Apply any special cross-jurisdictional rules
    if (hasSpecialPrivacyRule(fromJurisdiction, toJurisdiction)) {
        resultingPrivacyLevel = getSpecialPrivacyLevel(
            fromJurisdiction, 
            toJurisdiction
        );
    }

    assets[assetId].privacyLevel = resultingPrivacyLevel;
    return resultingPrivacyLevel;
}

Privacy Enforcement through Code

The enforcement of privacy rules in NEW-EIP is not just a matter of policy but is directly encoded in the smart contracts. Here’s how key privacy enforcement mechanisms are implemented:

// Privacy enforcement for asset transfers
function transferWithPrivacy(
    bytes32 assetId,
    address to,
    uint256 amount,
    bytes calldata zkProof
) external {
    // 1. Verify the sender has the asset
    require(balances[assetId][msg.sender] >= amount, "Insufficient balance");

    // 2. Check compliance status without revealing private details
    bool compliant = verifyComplianceWithPrivacy(
        assetId, 
        msg.sender, 
        to, 
        zkProof
    );
    require(compliant, "Transfer would violate compliance rules");

    // 3. Execute the transfer with appropriate privacy level
    uint256 privacyLevel = assets[assetId].privacyLevel;
    if (privacyLevel == 3) { // Highest privacy
        // Only emit encrypted event data
        balances[assetId][msg.sender] -= amount;
        balances[assetId][to] += amount;
        emit PrivateTransfer(assetId, keccak256(abi.encode(msg.sender, to, amount)));
    } else if (privacyLevel == 2) { // Medium privacy
        // Emit transfer with hashed addresses
        balances[assetId][msg.sender] -= amount;
        balances[assetId][to] += amount;
        emit SemiPrivateTransfer(
            assetId, 
            keccak256(abi.encode(msg.sender)), 
            keccak256(abi.encode(to)), 
            amount
        );
    } else { // Lower privacy
        // Standard transfer with full transparency
        balances[assetId][msg.sender] -= amount;
        balances[assetId][to] += amount;
        emit Transfer(assetId, msg.sender, to, amount);
    }
}

This pattern enables privacy-preserving transfers while maintaining appropriate regulatory visibility based on the asset’s privacy classification.

Beyond Implementation: The Philosophy of Privacy in Financial Regulation

While the technical implementations are crucial, the underlying philosophy guiding our approach to privacy deserves deeper exploration. Our work on NEW-EIP has been informed by several key principles:

1. Privacy as a Spectrum, Not a Binary: Privacy exists on a continuum that can be calibrated to specific contexts.
2. Proportionality: The level of disclosure should be proportional to legitimate regulatory needs.
3. Minimization: Only the minimum necessary information should be exposed, even to authorized parties.
4. Purpose Limitation: Access to private information should be limited to specific, declared purposes.
5. Auditability of Access: All access to private information should itself be recorded and auditable.

These principles extend beyond the technical implementation of NEW-EIP and reflect a broader philosophy about how financial systems should approach privacy in the digital age.

The Path Forward: Privacy Evolution

Privacy in regulated financial systems is not a static target but an evolving challenge. As regulations change and technologies advance, our approach to privacy must adapt. The NEW-EIP standard is designed with this evolution in mind, providing extension points for future privacy enhancements:

// Extensible privacy module interface
interface IPrivacyModule {
    function supportsPrivacyLevel(uint256 level) external view returns (bool);
    function executePrivateTransfer(
        bytes32 assetId,
        address from,
        address to,
        uint256 amount,
        bytes calldata privateParams
    ) external returns (bool);
    function verifyPrivateData(
        bytes32 dataHash,
        bytes calldata proof,
        bytes32 context
    ) external view returns (bool);
}

// Registry for privacy module extensions
mapping(bytes32 => address) public privacyModules;

function registerPrivacyModule(
    bytes32 moduleId,
    address moduleAddress
) external onlyGovernance {
    require(moduleAddress != address(0), "Invalid module address");
    require(privacyModules[moduleId] == address(0), "Module ID already registered");

    // Verify the module implements the required interface
    require(
        IPrivacyModule(moduleAddress).supportsPrivacyLevel(0),
        "Address does not implement IPrivacyModule"
    );

    privacyModules[moduleId] = moduleAddress;
    emit PrivacyModuleRegistered(moduleId, moduleAddress);
}

This extensibility ensures that as new privacy technologies emerge—such as more efficient zero-knowledge proof systems or advanced encryption techniques—they can be integrated into the NEW-EIP framework without requiring a complete redesign.

Conclusion

Privacy represents the second pillar of our NEW-EIP standard, complementing the Traceability pillar we explored previously. Through a three-layer architecture and the Privacy-Compliance Convergence Matrix, we’ve created a framework that enables regulated financial assets to maintain appropriate privacy while satisfying regulatory requirements.

This balanced approach transforms the traditional dichotomy between privacy and compliance into a nuanced spectrum where both can coexist. By encoding these privacy principles directly into the smart contract architecture, NEW-EIP provides a foundation for regulated financial assets that respects individual privacy while enabling necessary oversight.

The journey toward perfect privacy-compliance balance is ongoing, but the framework established in NEW-EIP represents a significant step forward in reconciling these seemingly opposing forces in decentralized financial systems.

---

References

1. Allen, J., et al. (2023). Privacy-Preserving Compliance: Challenges and Solutions for Digital Assets. Journal of Blockchain Research, 5(2), 78-92.
2. Financial Action Task Force (FATF). (2023). Updated Guidance for a Risk-Based Approach for Virtual Assets and Virtual Asset Service Providers. https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets.html
3. Buterin, V., & Weyl, E.G. (2024). Privacy and Legitimacy in Decentralized Society. Cryptoeconomic Systems Journal, 2(1). https://cryptoeconomicsystems.pubpub.org/
4. European Commission. (2024). Markets in Crypto-Assets Regulation Implementation Guidelines. https://ec.europa.eu/info/business-economy-euro/banking-and-finance/regulatory-process-financial-services/regulatory-process-financial-services_en
5. Narayanan, A., & Clark, J. (2023). The Technical Foundations of Privacy in Blockchain Systems. Communications of the ACM, 66(5), 84-93.
6. Goldwasser, S., Micali, S., & Rackoff, C. (1989). The knowledge complexity of interactive proof systems. SIAM Journal on Computing, 18(1), 186-208.