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
The bank asks. The board answers. A document comes out.
Most Shariah boards work with email, spreadsheets and a folder of PDFs. Nothing holds the decision: a ruling lives in an attachment, its conditions are read by whoever remembers them, a review date sits in somebody's calendar until that person leaves, and a desk waiting to sign an agreement waits weeks for an answer. Majlis is the board's own record and workplace, and it stands on its own — a bank can run it with nothing else from us attached.
It computes. It never concludes.
Every calculation in Majlis shows its arithmetic and stops before the ruling. Every reading of a contract quotes the passage and stops. Nothing in the software returns a field called compliant, permissible or approved — the ruling is the board's, in the board's own words, and the whole design exists to make sure nothing else is ever mistaken for it.
A question, worked one step at a time
The bank writes the question in its own words and attaches the draft. The board judges it against a named contract — murabaha, ijara, sukuk — one condition at a time. Every answer carries the name of the member who gave it and the reason they gave.
Nineteen contract types
Ten families, 89 conditions between them — sale, lease, partnership, agency, sukuk, sarf, security, gratuitous, takaful, and contracts in combination. They ship as drafts and bind nobody: a board adopts one, amends its conditions, declines it with a reason, or rules beside it. Every screen says which of those it is showing.
The draft, read against the conditions
Condition by condition: found with the passage quoted, unclear, or absent. None of the three is a verdict. A PDF is read in the browser on the desk's own computer — the file is never uploaded — and a scanned one is refused and told it is a scan, because twenty characters off a stamp would report every condition missing.
Six calculations, none of them a verdict
Screening against the board's own thresholds, purification by three methods that give three different answers, zakat on either base and either year, profit distribution with PER before the split and IRR after, tradability by what sits behind the paper, and a late-payment charge that has no field for becoming income. Every sum is shown; money is exact decimal throughout.
What it watches without being asked
A pool approved at 51% tangible drifts to 47% and nobody finds out until the audit — unless something is comparing. Majlis compares, counts review dates down, marks a restriction lapsed when its ratification window closes, and reports what was executed against what was approved. All four report. None of them re-rules.
What the bank gets back
Three screens of its own: what it asked and what became of it, what binds it today with the figures it has to hold to, and what it still owes. When the board decides, the written ruling is on the desk's own screen — and every condition the agreement failed comes back as a clause it has to add.
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. An installation that configures no model key has no assistant at all — the application says the assistant is off rather than answering anyway, and everything else in Majlis works without it. 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
The waiting period, the objection and the emergency restriction already run here. What is missing is the scholar’s own key: today a member signs a document this installation sealed, and Stage three is the member holding the key himself, so the vote is the signature that moves the registry.
Plurality
Multiple boards and institutions, cross-reference between them, and a published reference from the accumulated record.
Stage two is what exists today, and it is a working application rather than a demonstration of one: 36 addresses in the application, 145 routes on the server, 2 277 tests passing. A question arrives from the bank with its contract attached, the board judges it against a named contract type one condition at a time, votes with written reasoning — a vote is refused without it, because a position nobody can review, cite or disagree with later is not a record of anything — and the ruling comes out as a document the bank opens on its own screen. The record is append‑only: a correction supersedes rather than replaces, and what stands is derived from the chain of entries rather than from a timestamp. Three languages, English, Arabic and Urdu, with full right‑to‑left support. What it does not do is stated on every screen in the application itself. Nothing here signs on the board’s behalf: what a member signs is a sealed document attesting to an authentication this installation performed, not a scholar’s own key, and that key is Stage three. Unless an installation is wired to the registry, a decision taken in Majlis does not change what executes. Unless a mail relay is configured, nobody outside the application is told — the notice is composed and shown, and whether it was actually sent is stated rather than assumed. The Arabic and the 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.
Yes, and most will. Majlis is one installation for one institution — its own board, its own members, its own record, nothing shared with anybody else’s. The registry is something an installation can be wired to when the institution wants a decision to reach what executes; until then Majlis is the board’s record and workplace and says plainly, on the screen, that a decision taken here has not moved anything on a chain.
Four kinds of people, and none of them sees the others’ work. A desk at the bank writes a question in its own words, attaches the draft, and afterwards has three screens: what it asked and what became of it, what binds it today with the figures it has to hold to, and what it still owes. The secretariat takes the question, gives it a shape, convenes the meeting and keeps the record. A board member deliberates, answers the conditions one at a time in writing, and votes — and the vote is refused until every condition is answered, because voting on a matter half of which nobody has looked at is not a decision. The institution’s own officers see what was approved against what was executed. Every act carries the name of whoever did it.
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.