Skip to main content

TESTNET ONLY - Sepolia Testnet

Documentation

Architecture

ZadFi uses 4 singleton contracts plus one P2P Murabaha contract per financing agreement. Matching, collateral routing, and any configured samsarah fee are handled in the factory before the deal contract is created.

CollateralWhitelist - Token governance (Shariah Council)

MurabahaFactory - Marketplace for offers/requests

MurabahaContract - Factory-instantiated canonical contract (one per financing)

Current Sepolia deployment

Protocol release: v22

Factory version: v2

Deployment block: 11265571

Factory address: 0xc7f76a83d12e10a48faa411b46910e37b44db449

The samsarah fee is a fixed per-token ujrah. The interface reads the current on-chain value, requests its payment-token allowance separately, and signs a maximum fee cap with the match transaction.

Quick Guides

As Provider (3 steps)

  1. Choose asset + amount + terms
  2. Set markup, duration, and collateral policy
  3. Publish offer and wait for acceptance

As Seeker (3 steps)

  1. Find offer/request that matches your need
  2. Lock collateral and confirm wallet transaction
  3. Repay installments and recover collateral

Smart Contracts

CollateralWhitelist

Governs which tokens can be used as Murabaha assets and collateral.

// Token roles
Asset         -> Shariah Council approved asset token
Collateral    -> Shariah Council approved collateral token
PaymentToken  -> Shariah Council approved payment token

// Riba Protection: assetToken ≠ paymentToken

MurabahaFactory

Marketplace for providers to create offers and seekers to accept/fund them.

createOffer(assetToken, amount, paymentToken, salePrice, ...)
acceptOffer(offerId, collateralToken, collateralAmount, maxSamsarahFee)
createRequest(assetToken, minAmount, maxAmount, paymentToken, ...)
fundRequest(requestId, amount, salePrice, markupBps, maxSamsarahFee)
  • • Request collateral is escrowed at createRequest()
  • • Partial funding scales collateral and refunds unused amount
  • • Cancellation delay = state delay, not guaranteed offer fillability
  • • Riba Protection: assetToken ≠ paymentToken (enforced)
  • • The taker approves the fixed samsarah fee separately and signs its maximum cap at match time

MurabahaContract

Individual P2P financing contract instantiated by factory.

  • ✓ Immutable terms after creation
  • ✓ Installment tracking
  • ✓ Default settlement with fair collateral split
  • ✓ Full payment early option
  • ✓ Default can be claimed only after actual delinquency or grace expiry

ShariahCouncil

Multi-signature attestation for token-role approval.

  • ✓ Scholar multi-sig (3-7 signers)
  • ✓ Contract hash attestation
  • ✓ On-chain compliance record

Flows

Offer Flow (Provider)

  1. Provider creates offer with terms
  2. Seeker browses marketplace
  3. Seeker accepts with collateral
  4. Contract instantiated, asset transferred
  5. Seeker pays installments
  6. Completion or default settlement

Request Flow (Seeker)

  1. Seeker creates request with collateral escrowed
  2. Provider browses requests
  3. Provider funds request
  4. Contract instantiated
  5. Seeker pays installments

Security Measures

  • ✓ ReentrancyGuard on all external functions
  • ✓ SafeERC20 for token transfers
  • ✓ Input validation with Zod schemas
  • ✓ Abuse protection
  • ✓ Wallet signature authentication
  • ✓ CORS configuration
  • ✓ SQL injection protection
  • ✓ BigInt serialization fix
  • ✓ Connection pooling

Verification & Launch Readiness

Current proof snapshotJuly 1, 2026

This proof summary is generated from the verification artifacts bundled with the current frontend build.

Current snapshot

Certora Rules

Current snapshot

Specs

27/35

Proven Invariants

0

Open Properties

  • ✓ MurabahaContract now formally proves delinquency gating and exact grace-boundary behavior for default claims
  • ✓ Factory proofs cover whitelist revalidation when offers are accepted or requests are funded
  • ✓ Factory proofs cover distinct-token constraints across asset, payment, and collateral paths
Latest wrapper snapshotApril 18, 2026

Formal proofs reduce risk, but they are not the only launch gate. Mainnet still requires external review, certification, and final readiness checks.

  • • External security audit is still required before mainnet
  • • Shariah Council certification remains a launch prerequisite
  • • If a generated wrapper artifact ever lags, the Status page and docs remain the authoritative public record
Status