Encoding Shariah compliance into the token itself
Most Shariah-compliant fintech is compliance by PDF. ERC-3643 compliance modules can enforce Shariah screens at the transfer layer — sector exclusions, purification thresholds, profit-sharing ratios — in code that no intermediary can override.
Most Shariah-compliant fintech is compliance by PDF. A fund obtains a fatwa, attaches it to the offering memorandum, and relies on human administrators to honour it at every subsequent step. When the asset is tokenised, that PDF remains off-chain — advisory, not enforceable. The token itself has no knowledge of riba, no awareness of prohibited sectors, and no mechanism to route impure income to a waqf. Every transfer is structurally identical whether the underlying asset passed a Shariah screen or not.
ERC-3643 changes the geometry of this problem. Its compliance module architecture was designed for regulatory transfer restrictions, but the same hook that enforces accredited-investor status can enforce a debt ratio, a prohibited-income threshold, or a purification payment — in code that executes before settlement, not after it. This post works through what a serious ShariahComplianceModule would look like, what the standards actually require, and where the hard problems remain.
The AAOIFI Screening Framework
The Accounting and Auditing Organisation for Islamic Financial Institutions published Standard No. 21 (Financial Papers, May 2004) as the authoritative two-layer screen for equity securities. It has been adopted by the UAE Higher Shariah Authority as mandatory for all licensed Islamic institutions, including digital-asset governance.
Layer 1 — Qualitative Business Activity
Binary. If the company's primary or significant business falls into a prohibited category, it is excluded regardless of financial ratios. The categories: alcohol, pork products, gambling, conventional (interest-based) banking and insurance, weapons manufacturing, and pornography. No partial credit, no remediation threshold.
Layer 2 — Quantitative Ratios
- Interest-bearing debt / market capitalisation < 30%
- Interest-bearing assets / market capitalisation < 30%
- Non-permissible income / total revenue < 5%
Note what changed: AAOIFI SS 59 (Sale of Debt) removed the minimum tangible-asset floor that appeared in earlier readings of SS 21. AAOIFI currently has no explicit receivables ratio. This makes it more lenient on asset-light businesses than MSCI or FTSE — a deliberate doctrinal position, not an oversight.
Index Methodology Comparison
The three major Islamic index providers use materially different denominators and thresholds. For a tokenised security that claims compliance with a specific standard, the module must implement that standard's exact arithmetic — not a generic approximation.
| Provider | Denominator | Debt/Asset Threshold | Non-Permissible Income | Notes |
|---|---|---|---|---|
| AAOIFI SS 21 | Market capitalisation | < 30% | < 5% of total revenue | No explicit receivables cap since SS 59 |
| MSCI Islamic | Total assets | < 33.33% (entry), 33.33% retention | < 5% | Shariah-compliant debt excluded from ratio for 11 OIC-country issuers |
| DJIM | 24-month avg market cap | < 33% | < 5% | Separate liquidity screens apply |
| FTSE Shariah | Total assets | < 33% | < 5% | Follows AAOIFI for activity screens |
The MSCI carve-out for GCC countries, Bangladesh, Egypt, Indonesia, Malaysia, Pakistan, and Turkey — excluding sukuk and other Shariah-compliant instruments from the debt ratio numerator — is a meaningful difference when tokenising assets from those jurisdictions. Hardcoding the wrong denominator is a compliance failure, not a rounding error.
Purification: Three Methods, All Simple Arithmetic
When a compliant security earns a minor portion of income from impermissible sources (the < 5% threshold acknowledges this happens), the investor must donate the proportional income to charity. Scholars call this purification (tazkiyah). There are three accepted calculation methods, and all three reduce to arithmetic on oracle-supplied ratios.
- Dividend method: purification amount = dividend received × (non-compliant revenue / total revenue)
- Capital gains method: purification amount = (sale price − purchase price) × (non-compliant revenue / total revenue)
- AAOIFI annual method: total non-compliant revenue / total shares outstanding × shares held = annual per-share donation
A smart contract can calculate any of these at the point of dividend distribution or redemption, given a trusted oracle supplying the non-compliant revenue ratio, and route the resulting amount to a designated waqf (Islamic endowment) address automatically. No intermediary required, no investor discretion, no paperwork.
Purification is not optional for a compliant investor. If the token contract handles it automatically at settlement, the investor receives their net-compliant proceeds and the impure portion moves to waqf in the same transaction. That is structurally better than any manual process — it eliminates the gap between knowing the obligation and discharging it.
ERC-3643 Module Architecture
ERC-3643 separates identity (ONCHAINID) from compliance logic (pluggable modules). Nine pre-built modules ship with the reference implementation: CountryAllowModule, CountryRestrictModule, MaxBalanceModule, SupplyLimitModule, and five others. None is Shariah-specific. The extension point exists; the module does not.
A ShariahComplianceModule sits in the same architectural slot as these existing modules, implementing the IModule interface. The canTransfer hook runs before every token transfer. If the hook returns false, the transfer reverts. That is the enforcement point — not policy documentation, not post-trade surveillance, the transfer itself.
ShariahClaimTopicRegistry
Extends ONCHAINID's claim topic registry with Shariah-specific claim types: ASSET_SHARIAH_SCREENING (numeric, quarterly update), BUSINESS_ACTIVITY_STATUS (binary, annual), PURIFICATION_RATIO (decimal, per distribution event), and SHARIAH_BOARD_APPROVAL (soulbound, governance-controlled). Each claim type has an issuer allowlist — only whitelisted oracles and recognised Shariah boards can write these claims.
AssetShariahScreening
Holds the three AAOIFI ratios as on-chain state, updated quarterly via ShariahOracleAdapter from a trusted data provider. Stores: debtRatio (uint256, basis points), prohibitedIncomeRatio (uint256, basis points), businessActivityStatus (bool). The canTransfer check reads these values and reverts if any threshold is breached. When a ratio update pushes the asset out of compliance, new subscriptions are blocked immediately; existing holders are flagged for Transfer Agent review, matching IFSB guidance on remediation periods.
PurificationEngine
Activated at distribution events. Takes impureIncomeRatio from the oracle, calculates the per-token purification amount using whichever method is specified in the offering configuration, and splits the distribution: compliant proceeds to the investor's wallet, purification amount to purificationRecipient (a waqf contract address). Both transfers happen atomically. The investor cannot receive the full distribution and then fail to donate — the contract sequence eliminates that failure mode.
ShariahOracleAdapter
Thin adapter layer between the module and external data. Accepts ratio updates signed by a threshold of trusted oracle addresses (multisig pattern). Emits RatioUpdated events that compliance dashboards can index. Designed to be replaceable — if a better data provider emerges or a ratio methodology changes following a new fatwa, only the adapter is swapped, not the entire compliance module.
The Scholar Problem: IFSB and ISRA Positions
Automating compliance screens does not replace scholarly oversight — it implements it. The distinction matters for regulatory acceptance and for doctrinal validity.
IFSB Working Papers 27 and 28 (December 2023) are explicit: human Shariah board oversight is required for automated systems. The board must approve the ruleset encoded in the contract. ISRA's published position (ISRA International Journal of Islamic Finance, 12(3), 331–345) characterises smart contracts as tools, not replacements for scholars. Novel situations require scholarly ruling before the code can encode anything.
There is also a hard gap in the standards landscape: as of 2025, AAOIFI has published no standard specifically addressing crypto or digital assets. A roundtable was held at the 21st Shariah Council Conference in Manama on 8 May 2023; no standard followed. Practitioners are currently working from analogical reasoning applied to existing standards — which is the correct scholarly method, but means the rules encoded in any smart contract today may need amendment when formal standards arrive.
The correct architectural response is the upgradeable proxy pattern (EIP-1967). The Shariah board's approval is recorded as a Soulbound Token or a signed ONCHAINID claim. The code enforces the scholars' rules as currently approved. When a fatwa is updated or a new AAOIFI standard is published, the proxy is upgraded through a governance process that requires a new SBT issuance from the Shariah board. Scholars retain authority over novel rulings; the contract enforces whatever those rulings specify.
HAQQ Network: A Reference Point
HAQQ Network provides the nearest live reference for what on-chain Shariah governance looks like in practice. It is EVM-compatible, built on Cosmos SDK, and received its formal fatwa on 22 January 2022. The governance process uses a two-tier SBT system: a community governance vote, followed by a 21-day Shariah Board review period. The board included Sheikh Dr. Nizam Mohammed Saleh Yaquby, one of the most widely credentialled scholars in Islamic finance. Ten percent of ISLM emissions are allocated to the Evergreen DAO, which functions as an on-chain waqf.
HAQQ's design confirms that the pieces exist: on-chain waqf, SBT-based scholar approval, EVM compatibility. What it does not provide is an ERC-3643 compliance module enforcing asset-level screens. That is a different layer — issuer-level asset compliance rather than network-level governance.
The goal is not to eliminate Shariah scholars from the system. It is to make their rulings structurally binding rather than advisory. A PDF fatwa attached to an offering document is advisory. A signed claim that gates every token transfer is binding.
Implementation Roadmap
- Engage a recognised Shariah board before architecture is finalised — the board must approve the methodology, not merely the output
- Select a screening standard and denominator explicitly (AAOIFI SS 21, MSCI, DJIM, or FTSE) — document the choice and rationale in the offering configuration
- Configure the PurificationEngine method per offering — dividend method for income-distributing assets, AAOIFI annual method for mixed-income structures
- Designate the waqf recipient address at offering creation — this address is immutable post-deployment to prevent diversion
- Deploy behind an EIP-1967 upgradeable proxy — document the upgrade governance process in the offering memorandum
- Record Shariah board approval as a Soulbound Token or ONCHAINID signed claim, referencing the specific module version approved
- Build oracle adapter for quarterly ratio updates with multisig threshold for ratio writes and on-chain event log for auditability
Token-x is building the ShariahComplianceModule as a first-class ERC-3643 extension — ShariahClaimTopicRegistry, AssetShariahScreening, PurificationEngine, and ShariahOracleAdapter as deployable, auditable components for any tokenisation on the platform. Shariah board approval flows through the same ONCHAINID identity infrastructure used for KYC and investor accreditation. Purification is automatic at the contract level, routed to a waqf address designated at offering creation. Contact the Token-x team to discuss structuring a Shariah-compliant tokenised offering.