papers/lux-security-token-standard/sections/03-compliance-oracle.tex

\section{Compliance Oracle}
\label{sec:compliance}

\subsection{Architecture}

Transfer restrictions are evaluated by on-chain compliance oracles rather than hardcoded contract logic. Each security token references a compliance oracle contract that implements the restriction checking interface:

\begin{lstlisting}[language=Solidity,caption={Compliance oracle.}]
contract ComplianceOracle is ITransferRestriction {
    IIdentityRegistry public identityRegistry; // I-Chain DID registry
    mapping(bytes32 => Rule[]) public partitionRules;
    Rule[] public globalRules;

    struct Rule {
        RuleType ruleType;
        bytes params;
        bool active;
    }

    enum RuleType {
        WHITELIST,        // only whitelisted addresses
        ACCREDITATION,    // require valid accreditation credential
        JURISDICTION,     // block/allow specific jurisdictions
        LOCKUP,           // time-based transfer restriction
        MAX_HOLDERS,      // cap on total holder count
        MAX_BALANCE,      // cap on individual holding
        MIN_TRANSFER,     // minimum transfer amount
        VELOCITY          // maximum transfer frequency
    }

    function detectTransferRestriction(
        address from, address to, uint256 value
    ) external view override returns (uint8) {
        // Check global rules
        for (uint i = 0; i < globalRules.length; i++) {
            uint8 code = evaluateRule(globalRules[i], from, to, value);
            if (code != 0x00) return code;
        }
        return 0x00; // SUCCESS
    }

    function evaluateRule(
        Rule memory rule, address from, address to, uint256 value
    ) internal view returns (uint8) {
        if (!rule.active) return 0x00;

        if (rule.ruleType == RuleType.ACCREDITATION) {
            bytes32 did = identityRegistry.didOf(to);
            if (!identityRegistry.hasValidCredential(did, "accreditation")) {
                return 0x06; // ACCREDITATION_EXPIRED
            }
        }
        // ... additional rule evaluation
        return 0x00;
    }
}
\end{lstlisting}

\subsection{I-Chain DID Integration}

The compliance oracle queries the I-Chain identity registry to verify investor credentials. Each investor's DID contains verifiable credentials issued by KYC/AML providers (KYC providers integrated via I-Chain):

\begin{itemize}[nosep]
  \item \textbf{KYC credential}: Issued upon successful identity verification, contains verification level and expiry.
  \item \textbf{Accreditation credential}: Issued upon accredited investor verification per SEC Rule 501(a), contains basis (income, net worth, professional) and expiry date.
  \item \textbf{Jurisdiction credential}: Contains the investor's country and state/province of residence for jurisdictional rule evaluation.
  \item \textbf{AML credential}: Contains ongoing AML monitoring status, updated by continuous screening.
\end{itemize}

The oracle verifies credentials without accessing the underlying personal data, preserving investor privacy while enforcing compliance requirements.

\subsection{Formal Properties}

\begin{definition}[Compliance Policy]
A compliance policy $\Pi$ is a finite set of rules $\{r_1, r_2, \ldots, r_k\}$ where each rule $r_i : (\textsf{Address} \times \textsf{Address} \times \mathbb{N}) \to \{0, 1\}$ maps a (sender, receiver, amount) triple to a boolean decision.
\end{definition}

\begin{definition}[Sound Restriction]
A transfer restriction mechanism is \emph{sound} with respect to policy $\Pi$ if every transfer that the mechanism permits also satisfies $\Pi$: $\forall (s, r, v)$, if $\textsf{detectRestriction}(s, r, v) = 0$ then $\forall r_i \in \Pi$, $r_i(s, r, v) = 1$.
\end{definition}

\begin{definition}[Complete Restriction]
A transfer restriction mechanism is \emph{complete} with respect to policy $\Pi$ if every transfer that satisfies $\Pi$ is also permitted by the mechanism: $\forall (s, r, v)$, if $\forall r_i \in \Pi$, $r_i(s, r, v) = 1$ then $\textsf{detectRestriction}(s, r, v) = 0$.
\end{definition}

\begin{theorem}[Soundness and Completeness]
The compliance oracle transfer restriction mechanism is sound and complete with respect to the configured compliance policy $\Pi$, provided that the I-Chain identity registry returns correct credential status.
\end{theorem}

\begin{proof}
Soundness: \texttt{detectTransferRestriction} iterates over all rules in $\Pi$ (both global and partition-specific). If any rule $r_i$ evaluates to a non-zero restriction code, the function returns that code and the transfer is blocked. A transfer is permitted (code 0x00) only if every rule returns 0x00. By construction, code 0x00 is returned by \texttt{evaluateRule} only when the rule's condition is satisfied. Therefore, a permitted transfer satisfies all rules in $\Pi$.

Completeness: If all rules in $\Pi$ are satisfied for a given transfer, then each call to \texttt{evaluateRule} returns 0x00. The loop produces no non-zero code. The function returns 0x00, permitting the transfer.

The correctness assumption on the I-Chain registry is necessary because the oracle delegates credential verification to the registry. If the registry returns incorrect status (e.g., reports an expired accreditation as valid), soundness may be violated. The I-Chain registry's correctness is maintained by the DID credential verification protocol.
\end{proof}