Atomic migration
Liquidity moves from V2 to V3, or rebalances inside V3, in one transaction. It completes whole or it does not happen. There is no partial state to unwind and no moment where the protocol holds the assets.
The gap
A rule on paper cannot stop a transaction.
A board reviews an asset and records its decision. The transaction then runs through software that has never read that decision. Between the two sits a gap that review cannot close, because review happens before, and the transaction happens anyway.
How it works · three steps
Step one
The board decides, in Majlis.
A Shariah board reads a matter in ordinary language: what is proposed, the exact operative parameters, what is deliberately not being decided, and the mechanism underneath. Before it votes it sees which past transactions the proposed rule would have stopped. The decision, its reasoning and any dissent are kept.
MattersSimulationReasoning kept
Step two
The rule enters the Policy Registry.
What the board approved becomes a whitelist entry in GravitasPolicyRegistry on Arbitrum: which assets are compliant, which routers may be used, who may execute. The registry version is tracked on chain, and every change is an event anyone can read without asking us.
On-chain whitelistVersionedEvents emitted
Step three
Teleport has to pass it.
Every migration calls the registry before anything moves. Both tokens must come back compliant, the owner's EIP-712 intent must match, and the result must meet the minimums that owner signed. If any of that fails the whole transaction reverts and nothing happened at all.
AtomicEIP-712 intentReverts on failure
The protocol
The rule moves into the transaction path.
Three mechanisms carry the whole idea. Each one is a property of the contract rather than a promise about how it is used.
A registry the contract must ask
Every migration checks both tokens against an on-chain whitelist before anything moves. The check is not optional and cannot be routed around. An asset that is not on the list produces a failed transaction, not a warning.
Signed intent
The owner signs the exact terms with EIP-712 typed data. A nonce ties the signature to one execution, so the same signature cannot be used twice.
Swipe
Execution · one transaction
Seven steps. One transaction.
Hold the centre and the migration runs. Let go and it waits where it is. If any step fails, every step before it is undone and nothing happened at all.
01
Pre-check
Ownership of the position, compliance of both tokens and the deadline are verified before anything moves.
02
Decrease
Liquidity is withdrawn from the existing Uniswap V3 position.
03
Collect
The underlying tokens and the fees accrued to the position are transferred to the engine.
04
Burn
The old position NFT is destroyed and the state is left clean behind it.
05
Swap
An optional rebalancing swap through an authorised router, only if the signed intent asked for one.
06
Mint
The new position is minted directly to the owner’s address. It never rests with the protocol.
07
Refund
Remaining dust is returned by a Yul-optimised routine that saves about 2,000 gas per transaction.
Waiting. Nothing has been sent.
Trust model
The protocol never holds your keys or your funds.
Three invariants hold on every migration. Each one is enforced by the contract, not by the interface, and each one is written out in the technical specification with its proof of mitigation.
Nothing is taken.
The underlying tokens the owner holds are the same before and after, less only slippage and the service fee. Dust is returned inside the same transaction that created it.
balance start = balance end + fees + slippage
Enforced by _refundDustOptimized
Compliance is a condition, not a report.
Both tokens in the pair must be registered compliant. The check runs inside the call. A pair that fails it produces a custom error and a reverted transaction.
isCompliant(A) and isCompliant(B)
must both be true Enforced by verifyAssetCompliance
must both be true Enforced by verifyAssetCompliance
The outcome is fixed before it starts.
The result must meet the minimums the owner signed, or the whole transaction reverts. Nothing settles at a number nobody agreed to. This is what removes gharar from the execution.
minted >= minimum signed
out A >= min A, out B >= min B Enforced by the slippage bounds
out A >= min A, out B >= min B Enforced by the slippage bounds
Swipe
Try it
Hold, and watch the rule work.
Choose an asset pair and hold the gate open. The check runs the way the contract runs it, in order, and stops where the contract would stop. This is a demonstration, not a live call to the network.
Shariah
Four prohibitions, written into the contract.
These are the categories the registry is able to express. They are not an endorsement by any standards body, and Gravitas certifies nothing itself.
RibaInterest
Revenue comes from a service fee of five to ten basis points on a completed migration. The protocol lends nothing and pays nothing for time.
GhararUncertainty
Execution is atomic and the outcome is bounded by the owner's own signed minimums. A result that cannot meet them is not delivered at a worse number, it is not delivered at all.
MaysirSpeculation
The registry admits only assets a board has approved. Gambling and speculation tokens are not on the list.
Halal assetsVerification
The whitelist is on-chain and governed. Anyone can read its current state without asking us, and every change to it is an event.
Swipe
Gravitas enforces the rules a board writes into the registry. It does not implement, adhere to, or certify against any external standards body, and it does not decide what is compliant.
Majlis · for Shariah boards
Where the decision is made, and kept.
Gravitas makes an approved ruling enforceable at the moment of execution. That solves one problem and creates another: once a rule has operational force, the process by which it is proposed, understood and amended becomes the most sensitive part of the system.
The vote is the signature.
A scholar's vote does not produce a recommendation that someone else then executes. What is signed is a hash of the exact operative parameters as displayed at the moment of voting. The question "was what the board approved the same as what was deployed" becomes a comparison rather than a matter of testimony.
Matters
A plain-language brief, the operative parameters, what is deliberately not being decided, the mechanism, the simulation, and the deliberation record.
Rules in force
Every rule with its parameters, its hash, and a live check that the two still match. A mismatch means the record was altered.
Briefings
A standing brief on technological change: what changed, why, which rules it touches, and a question for the board. Never a conclusion.
Assistant
Explains mechanism in ordinary language with its sources named, and is prevented in code from issuing anything that reads as a ruling.
Record
Retained explanations and a one-action audit export carrying an integrity hash, readable without any knowledge of the application.
Swipe
The assistant
Three gates, and every one fails closed.
The failure this guards against is a faithful ruling founded on an unfaithful explanation. A wrong explanation does not fail loudly, it produces a confident scholar ruling correctly on a mechanism that does not exist. So the constraint lives in code rather than in the model's discretion. Pick a question and watch where it stops.
01
Lexical gate, before the model runsKnown ruling-seeking phrasings are refused without the model ever being called.
Waiting02
Semantic classificationA separate cheap call reads intent. Anything that is not an unambiguous no is refused.
Waiting03
Lexical gate on the way outIf ruling language survives into the answer, the answer is discarded and the exchange is escalated.
Waiting
The asymmetry
Permitting waits. Restricting cannot.
A delay protects when a change permits something, because the risk grows with everything done under it. The same delay is a hazard in the other direction: two days of continued activity on an asset found to be non-compliant is not caution, it is harm. Drag the clock and watch the two rules diverge.
00hours since the board voted
Permit an assetAdds a token to the whitelist. Scheduled, then held in public.
Scheduled48 h to wait
Restrict an assetRemoves a token. Takes effect at once, and lapses if the full board does not ratify it.
In forceRatify within 168 h
Permitting
48 hours
A change that permits something waits. Delay protects, because the risk of permitting wrongly grows with what is done under it.
Restricting
Immediate
Restriction takes effect at once and must be ratified by the full board within a defined window or it lapses.
Record and comprehension
The record, the briefings and the assistant. A test still asserts that no route can write a rule directly; matters are how a rule changes.
Deliberation
A board raises a matter, deliberates in threads, votes with written reasoning, and objects during a timelock. The vote is recorded. Nothing here signs.
The vote becomes the signature
Threshold signing moves into Majlis, with a timelock countdown and an emergency restriction path.
Plurality
Multiple boards and institutions, cross-reference between them, and a published reference from the accumulated record.
Stage two is what exists today. A board can take a decision here and the record shows who decided what and why — a vote is refused without written reasoning, because a position nobody can review, cite or disagree with later is not a record of anything. What Stage two still cannot do is sign: a decision taken in Majlis does not itself change the Policy Registry, and closing that gap is Stage three. Permitting is deliberately slow and restricting is deliberately fast, then ratified within a window or it lapses on its own. Three languages, English, Arabic and Urdu, with full right-to-left support — though the Arabic and Urdu still need a native reviewer and are marked as such in the source. Every record in the running application is fabricated demonstration data and represents no real scholar, board or institution.
Access is restricted. Contact the team for credentials.
Governance
Nobody changes the rules alone.
On testnet the registry has a single owner, which is fast and is not good enough for real money. For mainnet the ownership moves behind a multi-signature wallet and a timelock, so every compliance change is proposed by several people and then sits in public for two days before it can take effect.
Proposed by
Gnosis Safe, 3 of 5
Founder, co-founder, legal counsel, a Shariah scholar representative and a technical advisor. Three of the five must approve before anything is scheduled.
Held by
GravitasTimelock, 48 hours
The change is scheduled and waits. Institutional partners get two days to read it and object. After the delay anyone at all can execute it, which is the point. The contract is written, with no admin and no privileged executor.
Applied to
GravitasPolicyRegistry
The whitelist, the authorised routers and executor status. Ownership is transferred to the timelock with a two-step handover, and the timelock itself has no admin.
Swipe
GravitasTimelock is written, its ownership handover is tested, and the deployment procedure is in the repository.
Guardian, one of one, can pause in an emergency and can do nothing else.
What remains is deployment, not development: create the Safe, deploy the timelock, hand the registry over.
Community voting arrives after mainnet, not before.
Developers · integration
The compliance check happens before the mempool.
The SDK queries the registry before it simulates anything, so a non-compliant asset throws in your own process rather than reverting on chain and costing gas. Built on viem with runtime validation through zod, and no loose types in the core.
// npm install @gravitas/sdk viem zod
import { GravitasClient } from '@gravitas/sdk';
const client = new GravitasClient({
rpcUrl: 'https://sepolia-rollup.arbitrum.io/rpc',
chainId: 421614,
registryAddress: '0xbcaE...4679',
teleportV3Address: '0x5D42...E993',
});
// throws ShariahViolationError before anything is sent
await client.compliance.validateAsset(tokenAddress);
const migration = client.migration()
.tokenId(123n)
.newFee(3000)
.ticks(-887220, 887220)
.slippage(minMint0, minMint1, minDec0, minDec1)
.deadline(deadline);
const sim = await migration.simulate(wallet);
console.log(sim.gasEstimate);Every revert has a name.
AssetNotCompliantThe token is not on the Shariah-compliant whitelist.CooldownNotMetThe V2 migration cooldown for this path has not elapsed.InvalidSignatureThe EIP-712 signature is invalid, replayed or expired.DeadlineExpiredThe deadline in the signed intent has passed.SlippageExceededThe output fell below the minimum the owner signed.Integration kit
An OpenAPI description of the compliance API, a mock server, sandbox policies and end-to-end test scenarios, so a bank can run a proof of concept without touching the chain.
SDK reference
The fluent migration builder, the compliance client, EIP-712 helpers and the typed error surface.
Compliance checker
The on-chain interface an external protocol calls to ask whether an asset is permitted. A single view call, with no change to its own architecture.
Proof
Read it yourself.
Every contract below is deployed on Arbitrum Sepolia and built from the source in the public repository. Nothing on this page depends on trusting this page: the addresses are here, the source is on GitHub, and the two can be compared.
Redeployed on 23 August 2026
Until that date the bytecode on chain was a generation behind this repository: it carried no pause, no two-step ownership transfer, no policy version history, and no EIP‑712 signed intent, and its swap router pointed at an address holding no code on this network. Three further faults were fixed before the redeploy rather than after it. The addresses below are the current ones; the superseded pair is listed in the deployment record.
GravitasPolicyRegistryVerified
On-chain Shariah compliance whitelist. Governs token and router authorisation.
0x6f3bfb896DD9964C9c05dA88692bDf1b1b2C3F23TeleportV3Verified
Atomic V3 NFT position migration with EIP-712 signed intents.
0x6702C2CE6eD58ca3934eBBd785CaC1De8DCd85B4TeleportV2Verified
Atomic Uniswap V2 LP token migration with a pool stability limit and a cooldown. No Uniswap V2 exists on this testnet, so it has nothing to route through yet.
0xEDfF3dFdcdd7C04B11d9B614d5E0cd368f1e93c0GravitasTimelockVerified
The controller that will hold the registry. Ownership has not moved to it yet; that handover is a separate, deliberate step.
0xbFFAd90B2607e3E5926260B640BbcD1E128680BaSwipe
0Line coverage across the three contracts
0Contract tests passing
0Majlis tests passing
0Funds ever held by the protocol
Ahead of mainnet
Four institutions are waiting on the audit.
Four letters of intent are signed, each one conditional on the independent security audit and on mainnet deployment. Separately, a Shariah scholar has reviewed the mechanism and provided a letter stating that the technology is aligned with Shariah. Formal certification follows mainnet.
A letter of intent is not a contract and a scholar's letter is not a certification. Both are named here because they are what exists. Neither is counted as revenue, and neither is presented as compliance.
4Letters of intent, conditional on audit and mainnet
1Scholar's letter on the mechanism, certification to follow
0Revenue recognised, and none claimed
Where it stands
What is not true yet.
Everything below is a limitation, and we would rather you heard it from us than found it later.
Testnet only
Arbitrum Sepolia. No mainnet deployment has happened. Dashboard figures are simulated.
No external audit
An internal review is in the repository. A third-party audit has not been commissioned, because the round funding it has not closed.
No Shariah certification
A scholar has reviewed the mechanism and given a letter stating the technology is aligned. That letter is not a certification. Formal certification is in progress through AmanX Advisory, follows mainnet, and no date is claimed.
No signed contracts
Four letters of intent exist and every one is conditional on the audit and on mainnet. None is a commitment to buy, none has produced revenue, and none should be read as one.
One admin key
The registry owner controls the whitelist today. GravitasTimelock is deployed and verified, and the two-step handover is tested, but ownership has not been transferred to it — deliberately, until the audit is done — so the single key still holds.
Majlis reads the chain best-effort
Majlis reads only whether the registry is paused and who owns it. Both were checked against the deployed contract and answer correctly. A failed read is still reported as a failure rather than disguised, and no unverified read is presented as confirmed.
The Arabic and Urdu need a native reviewer
Terminology in Islamic finance is precise, and a plausible translation is not a correct one.
Coverage is not proof
Line coverage is 94.4 percent, invariant and fuzz tests pass, and every guard in the three contracts is exercised from both sides. None of that is proof of correctness, and undiscovered bugs remain possible.
Nothing on this page is financial, legal or religious advice.
Questions
The ones institutions actually ask.
Answered the way we would answer them in a room, without the parts that sound better than they are.
Because the board is the one who certifies. Gravitas is the machinery that enforces whatever a board decides, and the registry holds their list rather than ours. Certification of the protocol matters for procurement and is in progress. It is not what makes the enforcement work.
Read the contracts on Arbiscan and query the registry directly. Every compliance decision is emitted as an event. The one thing not to do is read the verified source and assume it matches the repository, because right now it does not, and the notice above says which two fixes are missing.
The transaction reverts and you keep what you started with, less the gas. There is no custody step, so there is no state where the protocol holds your position and fails.
Because an assistant that rules would be doing the board's work with none of the board's authority, and a wrong explanation there does not fail loudly. It produces a confident scholar ruling correctly on a mechanism that does not exist. The assistant sets out the mechanism the ruling attaches to, and the ruling stays with the people who are answerable for it.
Because it is the smallest complete case. One transaction carries a compliance decision, a custody risk and an execution guarantee, so it proves the model without asking anyone to move real money first.
No. It is charged once on a completed service, at five to ten basis points, and it does not accrue with time. Time is what makes a return riba.
A board telling us the registry cannot express a rule they need. That is the failure mode we watch for, and it is why Majlis shows the consequence of a rule before the board votes on it.
Contact
Speak with the team.
Institutions, Shariah boards and auditors. Tell us what you need to see and we will send it.