SukukFi Documentation

Overview

Welcome to SukukFi's official documentation!

SukukFi is the world's first on-chain marketplace connecting profitable businesses with DeFi capital through profit-sharing debt instruments. Unlike traditional interest-based lending, SukukFi enables businesses to raise debt secured against cash-flow and supply inventory, while DeFi investors earn yield from actual business profits.

Built on blockchain technology with embedded smart contract infrastructure, SukukFi transforms how global trade finance operates by bringing transparency, efficiency, and profit-sharing principles to business financing. Starting with the $1 trillion per annum Telecom Voice, Messaging & Data Industry, we're unlocking a new asset class of real-world yield opportunities.

Whether you're a business seeking working capital, a DeFi investor looking for uncorrelated returns, this documentation provides everything you need to understand and interact with the SukukFi ecosystem.

Getting Started

Welcome to SukukFi

SukukFi bridges the gap between real-world commerce and DeFi capital markets through profit-sharing mechanisms that benefit all parties involved. Our platform enables businesses to access liquidity for trade finance while offering investors exposure to profitable, revenue-generating enterprises.

Quick Start Guide

Navigate to SukukFi: Head to https://sukuk.fi ↗ to access the platform

Explore Available Pools: Review active financing pools and their terms before participating

Connect Your Wallet: Use a compatible wallet that supports multiple blockchain networks for deposits

Understanding SukukFi

What is SukukFi?

SukukFi operates on Islamic finance principles, specifically profit-sharing rather than interest-based lending. Traditional debt creates a creditor-debtor relationship with fixed interest payments. SukukFi creates a partnership where investors share in the actual profits generated by business operations.

Key Principles:

Mudarabah: Profit-sharing contracts where capital providers and entrepreneurs share returns according to pre-agreed ratios
Murabaha: Asset-backed sale contracts with transparent, predetermined profit margins
Asset-Backed Security: All financing is secured against real business assets, inventory, or cash flows

How SukukFi Works

The SukukFi Process:

Pool Creation: Financing pools are created for profitable businesses with specific terms and profit-sharing ratios
Capital Deposit: DeFi investors deposit stablecoins into pools and receive SukukFi bond tokens
Smart Contract Execution: Proprietary smart contracts automatically manage fund flows and profit distributions
Business Operations: Businesses use capital to fund suppliers and fulfil customer orders
Revenue Collection: Customer payments are collected through SukukFi-controlled banking infrastructure
Profit Distribution: Smart contracts automatically distribute profit shares to investors based on actual business performance

Why SukukFi is Different

SukukFi has embedded its proprietary smart contract infrastructure into the business and operational support systems used by telecom related technology companies to enable trade and commerce.
Smart contract infrastructure secures and controls the flow of money in deal chains involving telecom related technology companies.
Real yield, not token emissions; returns come from actual business profits, not inflationary token models or interest on debt.
Bond composability; SukukFi bond tokens are composable across DeFi allowing for secondary liquidity and use as a collateral asset (e.g. lend/borrow).
Institutional access; designed for DAOs, crypto funds, and qualified investors looking to diversify with low-correlated yield.

Products

SukukFi Bond Pools

SukukFi Bond Pools are smart contract-managed investment vehicles that connect DeFi capital with profitable businesses. Each pool represents a specific business or trade finance opportunity with defined terms, profit-sharing ratios, and security arrangements.

Pool Features:

Asset-backed security against business inventory and cash flows
Transparent profit-sharing ratios defined upfront
Real-time monitoring of business performance and cash flows
Automated fund distribution based on actual business results
ERC-4626 compatible tokenised vault structure with ERC-7540 asynchronous interactions

SukukFi Bond Tokens

When investors deposit stablecoins into SukukFi pools, they receive SukukFi Bond Tokens representing their proportional ownership of the pool and entitlement to profit shares.

Token Benefits:

Profit Participation: Earn yield from actual business profits, not interest payments
DeFi Composability: Use tokens as collateral across DeFi protocols
Secondary Liquidity: Trade tokens on AMMs for 24/7 liquidity
Transparent Tracking: Monitor business performance and profit distributions in real-time

Token Mechanics:

Tokens represent fractional ownership of the underlying business assets and cash flows
Profit distributions occur based on actual business performance
Token value reflects both principal protection and accrued profit shares
Fully transferable and compatible with DeFi infrastructure

Supported Industries

Current Focus: Wholesale Telecom Carrier Industry

SukukFi initially targets the $1 trillion per annum Telecom Voice, Messaging & Data Industry, providing working capital for technology companies that:

Trade voice minutes, SMS messaging, and data through IoT and roaming contracts
Sell to credit-worthy institutional customers (Hyperscalers, Government departments, Tier1 operators)
Require liquidity to bridge payment terms between suppliers and customers

Expansion Industries

SukukFi is expanding to support businesses across multiple sectors:

Financial Services:

Payments companies performing remittances
Fintechs involved in consumer micro credit, automotive, and real estate transactions

Energy Sector:

Companies involved in wholesale purchase of electricity and gas contracts

Digital Economy:

Game makers working with publisher networks and marketplaces
Digital media brands involved in programmatic advertising

International Trade:

Exporters of industrial/precious metals, agricultural/mineral commodities
Electronics, machinery, and automotive exporters

For Capital Providers

Who Can Invest

Eligible Investors:

Individual DeFi investors seeking uncorrelated returns
DAOs and crypto-native funds
Accredited investors and family offices
Institutional investors looking for real-world yield

Investment Process

Step 1: Pool Selection Review available pools, terms, and profit-sharing arrangements

Step 2: Deposit Capital Deposit supported stablecoins into chosen pools

Step 3: Receive Bond Tokens Automatically receive SukukFi Bond Tokens representing your pool share

Step 4: Monitor Performance Track business performance and profit distributions in real-time

Supported Assets

SukukFi deploys smart contracts across multiple blockchain networks to collect stablecoins from capital providers. When you deposit stablecoins on your chosen blockchain, you receive bond tokens on that same chain in your wallet. The platform then mints synthetic currency (USD or EUR) which is traded by telecoms on the CommTrade sidechain platform.

Supported Stablecoins across multiple networks:

USDT0
USDC.e
BYUSD (PYUSD on Berachain)
HONEY
USDa (Avalon)
USDe (Ethena)

For stablecoins on other blockchains, use bridging providers such as Stargate Finance

Expected Returns

Target APY: 10-20% base return from profit-sharing on business operations

Yield Enhancement Opportunities:

Provide liquidity on DeFi AMMs using SukukFi bond tokens
Compound returns by reinvesting profit distributions
Use bond tokens as collateral for additional DeFi strategies

Risk Considerations

Business Performance Risk: Returns depend on actual business profitability and performance

Liquidity Risk: Withdrawals may be delayed if capital is deployed in active business operations

Counterparty Risk: Risk that businesses may not perform as expected or default on obligations

Smart Contract Risk: Technical risks associated with blockchain and smart contract infrastructure

For Businesses

Eligibility Criteria

Primary Industries: Telecom-related technology companies involved in:

Trading traffic streams of voice minutes, SMS messaging, and data
IoT and roaming contract operations
Sales to credit-worthy institutional customers

Financial Requirements:

No minimum revenue thresholds - we assess interesting businesses and use cases across industries
Focus on commercialising transactions through our platform funding model
Aim to incubate promising use cases to scale their revenue

Benefits for Businesses

Access to DeFi Capital: Tap into global DeFi liquidity pools

Profit-Sharing vs Interest: Share profits rather than pay fixed interest costs

Operational Integration: Smart contracts embedded in business systems for seamless fund management

Flexible Terms: Customisable financing arrangements based on business needs

Growth Capital: Scale operations with access to patient DeFi capital

Technical Infrastructure

System Purpose

The WERC7575 smart contract system is the blockchain settlement layer within a multi-tier telecom wholesale voice traffic settlement ecosystem. It works in conjunction with off-chain platforms (COMMTRADE and WRAPX) and telecom OSS/BSS systems to enable efficient, transparent settlement of inter-carrier voice traffic transactions.

Multi-Tier System Architecture

Complete Ecosystem Overview

Layer-by-Layer Breakdown

TIER 1: Telecom OSS/BSS Systems

Components: Carrier operational systems (legacy telecom infrastructure)

Responsibilities:

Call Routing: Direct voice traffic between carriers
CDR Generation: Create Call Detail Records for every call
- Origin/destination numbers
- Call duration
- Timestamps
- Quality metrics
Rate Management: Apply agreed rates per destination/carrier
Real-Time Operations: 24/7 voice traffic handling

Output: CDRs (Call Detail Records) pushed to COMMTRADE

Example:

Carrier A routes call: +1-555-0100 → +44-20-7946-0958
Duration: 15 minutes
Rate: $0.02/minute
Cost: $0.30
CDR sent to COMMTRADE for accounting

TIER 2: COMMTRADE Platform (Off-Chain Smart Contract Engine)

Nature: Off-chain platform with smart contract capabilities

Responsibilities:

1. OSS/BSS Integration

Connects to multiple carrier OSS/BSS systems
Ingests CDRs in real-time
Normalizes data formats across carriers

2. Rate Exchange Management

Enforces bilateral rate agreements
Applies volume discounts
Handles rate updates
Manages currency conversions

3. Call Routing Logic

Least cost routing (LCR)
Quality-based routing
Load balancing
Failover management

4. Transaction Accounting

Records every voice traffic transaction
Applies agreed rates
Calculates per-carrier balances
Maintains detailed transaction history

5. Settlement Preparation

Settlements are accounted for in quasi-real-time and pushed when they reached a defined amount or timer
Generates settlement instructions

6. Data Push to WRAPX

Pushes individual settlement instructions (not batched)
WRAPX receives individual transactions for batching and blockchain execution
Provides transaction details for WRAPX validation and optimization

Example Settlement Period:

Week 1 Transactions (aggregated by COMMTRADE):
─────────────────────────────────────────────────
Carrier A → Carrier B: 1,000,000 minutes @ $0.02 = $20,000
Carrier B → Carrier C: 800,000 minutes @ $0.025 = $20,000
Carrier C → Carrier A: 500,000 minutes @ $0.03 = $15,000
Carrier A → Carrier C: 300,000 minutes @ $0.028 = $8,400
Carrier B → Carrier A: 600,000 minutes @ $0.022 = $13,200

COMMTRADE calculates net positions:
────────────────────────────────────
Carrier A: -$20,000 - $8,400 + $15,000 + $13,200 = -$200 (net payer)
Carrier B: +$20,000 - $20,000 - $13,200 = -$13,200 (net payer)
Carrier C: +$20,000 - $15,000 + $8,400 = +$13,400 (net receiver)

Individual settlement instructions sent to WRAPX:
──────────────────────────────────────────────────
Transaction 1: Transfer $200 from Carrier A to Carrier C
Transaction 2: Transfer $13,200 from Carrier B to Carrier C

(WRAPX will batch these into a single blockchain transaction)

TIER 3: WRAPX Platform (Off-Chain Settlement Entity)

Nature: Off-chain settlement management platform

Responsibilities:

1. Settlement Validation

Receives settlement instructions from COMMTRADE
Validates settlement calculations
Checks for discrepancies
Confirms carrier balances sufficient

2. Batch Optimization

Receives individual settlement instructions from COMMTRADE
Aggregates multiple instructions into optimized batches
Optimizes for gas efficiency
Groups similar operations
Schedules blockchain transactions

3. Blockchain Interaction

Acts as validator on WERC7575 contracts
Signs batch settlement transactions
Pushes batchTransfers() to blockchain
Monitors transaction confirmations
Handles failed transactions

4. Permit Management

Controls withdrawal permissions
Issues permit signatures for valid withdrawals
Enforces withdrawal rules:
No outstanding settlement disputes
Regulatory compliance checks
Sufficient liquidity maintained
AML/KYC validation

5. Dispute Resolution

Manages settlement disputes between carriers
Holds withdrawals during investigations
Coordinates with COMMTRADE for data verification
Releases funds when disputes resolved

6. Settlement Monitoring

Tracks all blockchain settlements
Generates settlement reports
Alerts on anomalies
Maintains audit trail

Example WRAPX Operation:

WRAPX receives individual instructions from COMMTRADE:
────────────────────────────────────────────────────────
Instruction 1: Transfer $500 from Carrier A to Carrier B
Instruction 2: Transfer $300 from Carrier B to Carrier C
Instruction 3: Transfer $400 from Carrier C to Carrier A
Instruction 4: Transfer $200 from Carrier D to Carrier E
... (50 total individual settlement instructions for 20 carriers)

WRAPX batches and optimizes:
────────────────────────────
• Aggregates all 50 individual instructions
• Applies netting algorithm
• Result: 12 net transfers (76% reduction)

WRAPX pushes single batch to blockchain:
──────────────────────────────────────────
batchTransfers(
    debtors:   [Carrier A, Carrier B, ...],
    creditors: [Carrier C, Carrier D, ...],
    amounts:   [200, 13200, ...]
)

Signed by: WRAPX validator private key
Gas cost: ~200k gas (vs. 1M+ gas if each instruction was separate blockchain tx)

TIER 4A: On-Chain Settlement Layer (WERC7575)

Purpose: Telecom Carrier Settlement Platform

Primary Users: Telecom carriers (wholesale voice traffic operators)

Core Function: Real-time settlement of inter-carrier voice traffic transactions

Use Case Flow

┌─────────────────────────────────────────────────────────────────────┐
│                    TELECOM SETTLEMENT FLOW                          │
└─────────────────────────────────────────────────────────────────────┘

Step 1: Carrier Onboarding
──────────────────────────
Carrier A (e.g., Verizon Wholesale) → KYC verification
Carrier B (e.g., AT&T Wholesale)   → KYC verification
Carrier C (e.g., T-Mobile Wholesale) → KYC verification

Each carrier gets:
• Wallet address on WERC7575ShareToken
• KYC verification from validator
• Telecom integration deployed (for settlement enforcement)

Step 2: Funding (Permissionless Deposit)
─────────────────────────────────────────
Carrier A deposits: 1,000,000 USDC
Carrier B deposits: 500,000 USDC
Carrier C deposits: 750,000 USDC

Deposits are PERMISSIONLESS (anyone KYC-verified can fund their wallet)
Reason: Carriers need to top up quickly to maintain service

Step 3: Voice Traffic & Settlement
───────────────────────────────────
Throughout the month:
• Carrier A routes 10M minutes through Carrier B's network → owes $500k
• Carrier B routes 8M minutes through Carrier C's network → owes $400k
• Carrier C routes 5M minutes through Carrier A's network → owes $250k

Settlement platform tracks all traffic via telecom integrations

Step 4: Batch Settlement Execution
───────────────────────────────────
Validator (settlement platform) calls:

batchTransfers(
    debtors:   [Carrier A, Carrier B, Carrier C],
    creditors: [Carrier B, Carrier C, Carrier A],
    amounts:   [500000, 400000, 250000]
)

Netting algorithm optimizes:
• Carrier A: -500k + 250k = -250k (net payer)
• Carrier B: +500k - 400k = +100k (net receiver)
• Carrier C: +400k - 250k = +150k (net receiver)

Only 3 state changes instead of complex multi-transfer cascade!

Step 5: Withdrawal (Permission Required)
─────────────────────────────────────────
Carrier B wants to withdraw 100k from their balance:

• Carrier B requests withdrawal from settlement platform (off-chain)
• Settlement platform validates request (e.g., no outstanding payments)
• Settlement platform issues permit signature:
  permit(Carrier B, Carrier B, 100k, deadline, v, r, s)
• Carrier B calls transfer() with permit → withdrawal succeeds

WHY PERMISSION REQUIRED?
• Prevents withdrawal during settlement disputes
• Ensures regulatory compliance (AML checks)
• Allows settlement platform to freeze fraudulent carriers
• Ensures carriers have sufficient liquidity for ongoing settlement obligations

Key Design Rationale: Settlement Layer

1. Permissionless Deposits (with KYC)

// Anyone can deposit IF they're KYC-verified
function deposit(uint256 assets, address receiver) external returns (uint256) {
    // No special permission needed
    // KYC check happens at mint() when shares are created
}

Why?

Carriers need to top up wallets quickly (24/7 operation)
No manual approval bottleneck
KYC requirement ensures regulatory compliance
Telecom integration already deployed = verified carrier

2. Dual Authorization for Withdrawals

A. Direct Transfer (owner withdraws their own funds)

function transfer(address to, uint256 value) public override {
    _spendAllowance(msg.sender, msg.sender, value); // ← Needs self-allowance permit!
    super.transfer(to, value);
}

Why self-allowance required?

Settlement disputes must be resolved before withdrawal
Prevents carriers from withdrawing during fraud investigation
Regulatory compliance (AML checks on large withdrawals)
Ensures sufficient liquidity for ongoing settlements
Settlement platform controls withdrawal timing

B. Third-Party Transfer (authorized party withdraws on owner's behalf)

function transferFrom(address from, address to, uint256 value) public override {
    _spendAllowance(from, from, value);        // ← Platform authorization (self-allowance)
    return super.transferFrom(from, to, value); // ← Owner delegation (caller allowance)
}

Why BOTH allowances required?

This is a dual-authorization model:

Self-Allowance (allowance[from][from]): Platform/validator permission
- "Settlement platform permits this carrier to withdraw funds"
- Set by: Validator via permit signature
- Checks: No outstanding settlements, no disputes, compliance verified
Caller Allowance (allowance[from][caller]): Owner delegation
- "Carrier delegates authority to this third party"
- Set by: Carrier via standard approve()
- Enables: Smart contract automation, authorized operators

Real-World Example:

Carrier A wants to use InvoicePaymentContract to auto-pay suppliers:

Step 1: Request platform permission
→ Carrier A requests withdrawal clearance from WRAPX
→ WRAPX verifies: no disputes, sufficient balance, compliance OK
→ WRAPX issues permit: allowance[CarrierA][CarrierA] = 1M USDC

Step 2: Delegate to smart contract
→ Carrier A: approve(InvoicePaymentContract, 500k USDC)
→ allowance[CarrierA][InvoicePaymentContract] = 500k

Step 3: Automated payment execution
→ InvoicePaymentContract calls: transferFrom(CarrierA, Supplier, 100k)
→ Checks platform authorization: allowance[CarrierA][CarrierA] ≥ 100k ✓
→ Checks owner delegation: allowance[CarrierA][Contract] ≥ 100k ✓
→ Payment succeeds, both allowances reduced by 100k

Benefits:

Platform maintains oversight (prevents unauthorized withdrawals)
Carrier retains control (can delegate to trusted parties)
Smart contract integration possible (with platform approval)
Granular control (different limits for platform vs. delegation)

3. Batch Settlement Optimization

function batchTransfers(
    address[] calldata debtors,
    address[] calldata creditors,
    uint256[] calldata amounts
) external onlyValidator nonReentrant returns (bool)

Why?

Gas Efficiency: Thousands of inter-carrier transactions per month
Netting: Carrier A owes B, B owes C, C owes A → optimize to single net transfer
Atomic Settlement: All or nothing (prevents partial settlement)
Regulatory Audit Trail: Single transaction for entire settlement period

Example Optimization:

Without netting: 1000 individual transfers = 51M gas
With netting:    200 net transfers = 10M gas
Savings:         80% gas reduction

4. rBalance System for Investment Tracking

// Tracks investment contract's funds: available vs. invested
_balances[investmentContract]  // Available for funding
_rBalances[investmentContract] // Invested in deals (not yet returned)

_balances[investmentContract] - Available for funding
_rBalances[investmentContract] - Invested in deals (not yet returned)

Why?

Investment Tracking: Investment contract deploys capital into telecom deals
Yield Distribution: When deals profitable, adjust rBalance to reflect returns
Liquidity Management: Know how much available for new deals vs. locked in existing deals
Regulatory Reporting: Separate liquid funds from invested capital

Note: Carriers do NOT have rBalance tracking. Only the investment contract (ShareTokenUpgradeable) uses rBalance to track its deployed capital and returns.

Example:

Investment contract (ShareTokenUpgradeable) has 1M USDC deposited in settlement layer:
• _balances[investmentContract] = 600k (available for funding new deals)
• _rBalances[investmentContract] = 400k (invested in deals, earning yield)

When deal returns 20% profit:
• adjustrBalance(investmentContract, 400k invested, 480k returned)
• _balances[investmentContract] = 600k (unchanged - still available)
• _rBalances[investmentContract] = 480k (increased from 400k)
• Investment contract earned 80k profit (480k - 400k)

TIER 4B: Investment Layer (Upgradeable)

Purpose: Investment Capital for Telecom Deals

Primary Users: Investors (not telecom carriers)

Core Function: Collect investment capital and deploy it into settlement contract to fund telecom traffic deals

Use Case Flow

┌─────────────────────────────────────────────────────────────────────┐
│                    INVESTMENT FLOW                                  │
└─────────────────────────────────────────────────────────────────────┘

Step 1: Investor Onboarding
────────────────────────────
Investor deposits USDC → ERC7575VaultUpgradeable

Request → Fulfill → Claim (ERC-7540 async flow)
• Request: Investor transfers USDC to vault
• Fulfill: Investment Manager converts to shares (when ready)
• Claim: Investor receives IUSD shares

Step 2: Investment Deployment
──────────────────────────────
Investment Manager takes vault's idle USDC and invests:

investAssets(amount) → deposits into WERC7575Vault (Settlement Layer)

WERC7575Vault mints WUSD shares to ShareTokenUpgradeable

ShareTokenUpgradeable holds WUSD shares on behalf of investors

Step 3: Telecom Deal Funding
─────────────────────────────
Investment capital in Settlement Layer used for:
• Funding carrier prepayments
• Working capital for voice traffic deals
• Margin for settlement float
• Emergency liquidity reserves

Step 4: Yield Generation
────────────────────────
Telecom deals generate profit:
• Settlement fees from carriers
• Voice traffic margins
• Discount on prepayments

Settlement platform adjusts rBalance:
adjustrBalance(ShareTokenUpgradeable, invested, returned)

Step 5: Investor Redemption
────────────────────────────
Investor wants to exit:

• Request redemption of IUSD shares
• Investment Manager withdraws from Settlement Layer
• Investor receives USDC + profit

Key Design Rationale: Investment Layer

1. Async Operations (ERC-7540)

// Request → Fulfill → Claim
function requestDeposit(uint256 assets, address controller, address owner)
function fulfillDeposit(address controller, uint256 assets)
function deposit(uint256 assets, address receiver)

Why?

Capital Efficiency: Batch investments when deals available
Liquidity Management: Don't need instant execution
Professional Management: Investment Manager decides timing
Risk Management: Can delay during high volatility

2. Investment into Settlement Contract

function investAssets(uint256 amount) external returns (uint256 shares) {
    // Deposit into WERC7575Vault (Settlement Layer)
    shares = IERC7575($.investmentVault).deposit(amount, $.shareToken);
}

Why?

Direct Exposure: Investors get yield from actual telecom settlements
Transparent: Investment goes directly into operational contract
Measurable: Can track WUSD shares representing settlement position
Liquid: Can withdraw from settlement (with permission) when needed

3. Upgradeable Architecture

contract ERC7575VaultUpgradeable is UUPSUpgradeable, OwnableUpgradeable

Why?

Regulatory Adaptation: Investment products may need compliance updates
Feature Additions: Can add new investment strategies
Bug Fixes: Can patch issues without redeploying
Different Standards: Settlement layer is battle-tested, investment layer evolves

System Interaction: Two Layers Working Together

Capital Flow

INVESTORS                    INVESTMENT LAYER              SETTLEMENT LAYER              CARRIERS
   │                              │                              │                          │
   │ 1. Deposit USDC              │                              │                          │
   ├─────────────────────────────►│                              │                          │
   │                              │                              │                          │
   │                              │ 2. Invest USDC               │                          │
   │                              ├─────────────────────────────►│                          │
   │                              │                              │                          │
   │                              │    (WUSD shares to           │                          │
   │                              │◄─────ShareToken)             │                          │
   │                              │                              │                          │
   │                              │                              │ 3. Fund telecom deals    │
   │                              │                              ├─────────────────────────►│
   │                              │                              │                          │
   │                              │                              │ 4. Settlements & fees    │
   │                              │                              │◄─────────────────────────┤
   │                              │                              │                          │
   │                              │ 5. Yield generated           │                          │
   │                              │    (rBalance adjustments)    │                          │
   │                              │◄─────────────────────────────┤                          │
   │                              │                              │                          │
   │ 6. Redeem + profit           │                              │                          │
   │◄─────────────────────────────┤                              │                          │
   │                              │                              │                          │

Yield Generation Mechanism

Settlement Layer generates profit from:

Settlement Fees: Carriers pay fee per settlement
Voice Traffic Margins: Buy/sell voice minutes
Prepayment Discount: Carriers prepay for volume discounts
Liquidity Services: Premium for instant settlement

Profit Distribution:

Settlement platform calculates returns per period
Calls adjustrBalance() on ShareTokenUpgradeable's position
ShareTokenUpgradeable's WUSD shares increase in value
IUSD share price increases proportionally
Investors can redeem IUSD for more USDC than deposited

Example: End-to-End Flow

Month 1:
────────
• Investor deposits 100k USDC → receives 100k IUSD shares
• Investment Manager invests 100k USDC → Settlement Layer
• Settlement Layer mints 100k WUSD shares → ShareTokenUpgradeable
• Investment used to fund Carrier A's traffic deals

Month 2:
────────
• Settlement activity generates 10k profit
• Settlement platform adjusts: adjustrBalance(ShareToken, 100k, 110k)
• ShareTokenUpgradeable now has 110k value in Settlement Layer
• IUSD share price: 110k / 100k = 1.10 USDC per IUSD

Month 3:
────────
• Investor redeems 100k IUSD shares
• Investment Manager withdraws 110k USDC from Settlement Layer
• Investor receives 110k USDC
• Profit: 10k USDC (10% return)

Why Two Separate Systems?

Separation of Concerns

Aspect	Settlement Layer	Investment Layer
Users	Telecom carriers	Investors
Purpose	Operational settlement	Capital deployment
Deposits	Permissionless (with KYC)	Async (managed)
Withdrawals	Permission required	Managed by IM
Architecture	Non-upgradeable (stable)	Upgradeable (flexible)
Standards	ERC-20, ERC-2612	ERC-7540, ERC-4626

Why Settlement is Non-Upgradeable

Stability is Critical:

Handles millions in carrier funds
Real-time settlements cannot fail
Carriers need certainty of behavior
Battle-tested code = lower risk
Regulatory approval = hard to change

Why Investment is Upgradeable

Flexibility is Valuable:

Investment products evolve
Regulatory requirements change
Can add new features (e.g., different yield strategies)
Bug fixes without affecting carriers
Can adapt to market conditions

Centralization Rationale in Context

Settlement Layer Centralization

Why WRAPX (Validator) Controls Withdrawals:

Real-world scenario:
─────────────────────
Carrier A withdraws 1M USDC
BUT they have 500k outstanding settlement with Carrier B
PROBLEM: Carrier B cannot settle now!

Solution: WRAPX permit system
────────────────────────────────────
Carrier A requests withdrawal → WRAPX checks via COMMTRADE:
  ✓ No outstanding disputes (COMMTRADE confirms)
  ✓ No pending settlements (COMMTRADE confirms)
  ✓ Regulatory compliance (KYC status current)
  ✗ Large withdrawal → manual review

Only after approval → WRAPX issues permit signature → withdrawal succeeds

Why Batch Settlements by WRAPX (Validator):

Without batching (direct OSS/BSS → blockchain):
───────────────────────────────────────────────
1000 carriers × 100 transactions each = 100,000 individual blockchain transfers
Cost: Prohibitively expensive in gas
Risk: Some transfers fail = inconsistent state
No optimization possible

With multi-tier architecture (OSS/BSS → COMMTRADE → WRAPX → blockchain):
─────────────────────────────────────────────────────────────────────────
TIER 1 (OSS/BSS): Generates CDRs for all voice traffic
TIER 2 (COMMTRADE):
  • Aggregates CDRs
  • Calculates net positions
  • Sends individual settlement instructions to WRAPX
TIER 3 (WRAPX):
  • Receives individual settlement instructions from COMMTRADE
  • Batches multiple instructions together
  • Optimizes with netting algorithm
  • Pushes single atomic batch to blockchain
TIER 4 (Blockchain): Executes batched settlement

Result: 100,000 CDRs → 5,000 settlement instructions → 200 batched blockchain txs
Cost: 95% gas savings
Risk: All-or-nothing = consistent state
Benefit: COMMTRADE handles complex rate logic, WRAPX optimizes blockchain efficiency

Why KYC Required:

Regulatory requirement:
──────────────────────
Telecom settlements = financial services
Multi-jurisdiction carriers = AML compliance
Large transaction volumes = monitoring required
Fraudulent carriers = industry risk

Solution: KYC before wallet creation
────────────────────────────────────
Every carrier verified before COMMTRADE integration
Telecom OSS/BSS integration = identity verification
WRAPX maintains KYC status
Ongoing monitoring via COMMTRADE suspicious activity detection

Why Multi-Tier Architecture (OSS/BSS → COMMTRADE → WRAPX → Blockchain):

Single-tier approach problems:
──────────────────────────────
❌ Every CDR becomes a blockchain transaction = cost prohibitive
❌ Rate logic on-chain = complex, expensive, hard to update
❌ OSS/BSS systems can't directly interact with blockchain
❌ No optimization layer for gas efficiency
❌ Dispute resolution requires on-chain arbitration

Multi-tier benefits:
────────────────────
✅ TIER 1 (OSS/BSS): Legacy systems work as-is, no blockchain knowledge needed
✅ TIER 2 (COMMTRADE):
   • Complex rate logic off-chain, flexible, updateable
   • Aggregates CDRs and calculates net positions
   • Sends individual settlement instructions (not batches)
✅ TIER 3 (WRAPX):
   • Receives individual instructions from COMMTRADE
   • Batches instructions for blockchain efficiency
   • Gas optimization through netting algorithm
   • Dispute handling and permit management
✅ TIER 4 (Blockchain): Immutable settlement record, transparent, auditable

Cost efficiency:
───────────────
1M CDRs/month → COMMTRADE aggregates and sends instructions →
WRAPX batches into ~ X blockchain tx/day = 30X blockchain txs/month
Without tiers: 1M blockchain txs/month (33,333x/X more expensive!)

Investment Layer Centralization

Why Investment Manager Controls Fulfillment:

Capital efficiency scenario:
───────────────────────────
100 investors deposit throughout the month
Each wants immediate shares
BUT only deploy capital when large deal available

Solution: Async fulfillment
───────────────────────────
Investors request deposits (assets secured)
Investment Manager waits for optimal deal
Fulfills all deposits together when deal ready
Capital efficiency: 100% deployed vs. 20% idle

Why Investment Manager Controls Timing:

Risk management scenario:
────────────────────────
High volatility period in telecom markets
Investor requests redemption
BUT withdrawing now = selling at loss

Solution: Managed redemption
────────────────────────────
Investment Manager delays fulfillment
Waits for markets to stabilize
Fulfills when profitable exit available
Protects investor returns

Security Considerations in Context

Settlement Layer Security Priorities

Critical Invariants:

Zero-Sum Settlements: Batch transfers never create/destroy value
Liquidity Protection: Can't invest reserved settlement funds
Withdrawal Safety: Permit system prevents unauthorized exits
Atomic Settlements: All transfers succeed or all revert

Attack Vectors to Consider:

Manipulating batch netting for profit
Withdrawing during settlement to cause failure
Double-spending settlement obligations
rBalance manipulation to fake profits

Investment Layer Security Priorities

Critical Invariants:

Reserved Asset Protection: Investment can't touch pending/claimable funds
Share Accounting: IUSD supply matches underlying WUSD position
Fulfillment Accuracy: Pending → claimable conversions correct
Investment Safety: Can't over-invest beyond available balance

Attack Vectors to Consider:

Manipulating reserved asset calculation to over-invest
Exploiting async flow for double-claims
Front-running fulfillment operations
Storage corruption during upgrades

Integration Notes for Auditors

Understanding Context is Critical

Common Misconception: "Why can't users withdraw freely? This is centralized censorship!"

Reality: This is a settlement platform for commercial counterparties, not a consumer wallet.

Analogous to: Banking (can't withdraw during fraud investigation), Escrow (can't withdraw without counterparty release), Clearing House (can't exit during settlement period).

Proper Audit Question: "Can withdrawal permission be abused to steal funds?" "Are there safeguards against validator refusing legitimate withdrawals?"

What Makes This Different from DeFi

DeFi Standard	WERC7575 Settlement
Permissionless access	KYC required (regulatory)
Instant withdrawals	Permission required (settlement safety)
No operator control	Validator controls (operational necessity)
Code is law	Code + legal agreements
Trust-minimized	Trust professional operators

This is NOT a bug, it's the business model.

Conclusion

The WERC7575 system implements:

Settlement Layer: Operational platform for telecom carrier settlements
- Permissionless deposits (operational necessity)
- Permission-required withdrawals (settlement safety)
- Batch settlement optimization (cost efficiency)
- Non-upgradeable architecture (stability)
Investment Layer: Capital deployment into settlement operations
- Async operations (capital efficiency)
- Professional management (risk management)
- Upgradeable architecture (regulatory flexibility)
- Yield generation from telecom settlements

Both architectures are centralized BY DESIGN for legitimate business reasons, not due to oversight or lack of sophistication.

Auditors should focus on: Security vulnerabilities within the intended design, Business logic correctness, Standards compliance, Upgrade safety.

NOT: The centralization itself, Comparison to DeFi ideals, Philosophical objections.

Document Version: 1.0

Last Updated: 2025-01-05

Context: Telecom Wholesale Voice Traffic Settlement + Investment Platform

Liquidity & Redemption

Withdrawal Process

SukukFi utilises ERC-7540 token standard enabling asynchronous interactions with tokenised vaults:

Immediate Withdrawal: Available when stablecoins remain undeployed in pools

Delayed Withdrawal: Required when capital is actively deployed in business operations

Process Steps:

Submit withdrawal request through smart contract
System checks capital availability
If available: Immediate execution
If unavailable: Queue for next available liquidity (customer payment or new deposits)

Secondary Market Liquidity

24/7 Trading: Trade SukukFi bond tokens on DeFi AMMs and secondary markets

Market Making: Kodiak AMM integration on Berachain provides liquidity infrastructure

Sharia Principles

Islamic finance is grounded in Shariah, derived from the Quran and the Sunnah, and aims to promote justice, partnership, and real-economy value creation. Financing must be tied to lawful trade or assets, with risks and rewards shared fairly among participants.

Core Prohibitions

Riba (interest): Money cannot generate money by itself; returns must come from real economic activity.
Gharar (excessive uncertainty): Contracts must avoid ambiguity in price, subject matter, or delivery.
Maysir (speculation/gambling): Excessive risk-taking or zero-sum speculation is prohibited.
Haram activities: Financing cannot support prohibited sectors (e.g., alcohol, gambling, pornography, pork).
Unjust enrichment: Transactions should avoid exploitation and imbalance between parties.

Positive Requirements

Asset-backed or asset-based financing: Transactions are linked to tangible assets or services.
Risk sharing: Profit and loss are shared according to agreed ratios.
Clear, transparent contracts: Ownership and terms are defined upfront to reduce disputes.
Ethical impact: Investments should deliver social value beyond pure financial return.

Common Shariah-Compliant Structures

Practical structures include Mudarabah (profit-sharing), Musharakah (joint venture), Murabaha (cost-plus sale), Ijara (lease), and Sukuk (asset-based certificates). Where risk protection is needed, Takaful (mutual insurance) is preferred over conventional insurance.

Mudarabah (profit-sharing partnership)

One party provides capital (rab al-mal) and the other provides expertise and management (mudarib). Profits are shared according to a pre-agreed ratio, while financial losses are borne by the capital provider unless mismanagement or negligence is proven. This structure aligns incentives by linking returns to real performance rather than guaranteed interest.

Musharakah (joint venture)

All partners contribute capital and may participate in management. Profits are distributed based on agreed ratios, while losses are shared in proportion to each party's capital contribution. Musharakah is often used for project financing where shared ownership and shared risk are appropriate.

Murabaha (cost-plus sale)

A financier purchases a specified asset and sells it to the customer at a disclosed cost plus an agreed profit margin, often with deferred payments. The key Shariah features are clear asset ownership, transparency of price, and a fixed profit that is not tied to interest on money.

Ijara (lease)

The financier buys an asset and leases it to the customer for a defined period and rental amount. Ownership remains with the lessor, while use is transferred to the lessee. Maintenance responsibilities and eventual transfer of ownership (if agreed) are specified upfront to avoid uncertainty.

Sukuk (asset-based certificates)

Sukuk represent proportionate ownership in underlying assets, usufruct, or services. Returns are derived from the performance of those assets (e.g., lease income or profit shares) rather than interest payments. Structures are designed to link investor returns to real economic activity with clear asset linkage.

Takaful (mutual insurance)

Participants contribute to a pooled fund that provides mutual protection against defined losses. The fund is managed on a cooperative basis, and any surplus after claims and costs may be redistributed to participants. This avoids conventional insurance structures that rely on excessive uncertainty or interest-based investment.

Governance and Oversight

Shariah compliance is typically overseen by qualified scholars who review products, contracts, and ongoing operations. Interpretations can vary across jurisdictions, so transparent documentation and clear contractual design are essential.

How SukukFi Aligns

Profit-based returns: Investors earn from business performance, not fixed interest.
Asset-linked financing: Capital is deployed into real trade flows and measurable cash flows.
Risk sharing: Returns reflect actual outcomes, aligning incentives between participants.
Permissible activity screening: Financing targets lawful business activity.
Transparent terms: Smart contracts encode clear profit splits, obligations, and timelines.

Risk Management

Business Risk Assessment

Credit Assessment: We assess debtor creditworthiness internally using our telecom industry expertise and experience

Case-by-Case Evaluation: Each telecom business case is automatically governed by the CommTrade platform for commercial viability; then validated and verified by WrapX before settlement. This automated underwriting process is uniquely position to support industries like telecom where there is huge volume throughput of transactions to be settled and funded.

Capital Provider Choice: Ultimate credit risk assessment lies with capital providers determining their liquidity allocation

Operational History: No minimum operational history requirements - focus on securing financial flow security

Investor Protection

Asset-Backing: All investments secured against real business assets

Performance Monitoring: Continuous oversight of business operations through CommTrade platform

No Credit Insurance: Credit insurance is not provided in compliance with Sharia principles

Platform Fees

Fee Structure

Performance Fees: A fee of 20% charged to investors on generated profit/yield

Settlement Fees: 0.15% fee charged to customers on CommTrade platform when sending liquidity to suppliers

Telecom Transaction Fees: $0.00015 per telecom transaction fee (telecom transactions are voice minutes, messages and/or data packets) charged to users of the CommTrade platform

No Management Fees: No ongoing management fees charged to investors

No Withdrawal Fees: Free withdrawals for all investors

Use Cases

Introduction

Invoices are the formal records of commercial activity: they document what was sold, when, in what quantity, and at what price, and they establish payment terms that are legally binding. Invoices also sit at the heart of day-to-day cash flow management, tracking accounts receivable (what customers owe) and accounts payable (what a business owes its suppliers).

In practice, invoices are used to accelerate collections, reconcile sales, and resolve disputes. They can be issued in different forms depending on the transaction (standard, commercial, proforma, recurring, or VAT), but all require core details like a unique invoice number, dates, pricing, taxes, and payment terms.

Traditional invoice finance lets businesses access working capital before customers pay. A lender advances a percentage of an invoice (often 80–90%), collects payment later, and returns the balance minus fees. This is commonly structured as invoice factoring (lender collects) or invoice discounting (business collects).

Use Case 1 - Postpaid Funding for Telecom Carrier Voice Traffic

Wholesale telecom carriers provide the global backbone for voice traffic. They buy and resell large volumes of call termination, route traffic between networks, and enable services like VoIP, mobile calling, and unified communications. The industry is shifting to IP-based routing and cloud platforms, with 5G raising capacity and lowering latency.

Carriers rely on Least Cost Routing (LCR) to select the most economical routes in milliseconds based on live rate decks while still meeting quality thresholds like ASR, ACD, and post-dial delay. Because margins are thin, accurate rate data, quality monitoring, and redundancy are critical. Arbitrage opportunities exist where termination rates or regulatory structures diverge, which makes transparent routing and audit trails essential.

Billing and settlement depend on Call Detail Records (CDRs). CDRs capture call metadata (origin, destination, timestamps, duration, routing, and termination cause) that are normalized, rated, and aggregated into itemized invoices. These records power reconciliation, dispute resolution, and revenue assurance across inter-carrier relationships.

Use Case 2 - Postpaid Funding for Application 2 Phone (A2P) Messaging (SMS) Traffic

The A2P messaging industry covers automated business-to-consumer communications delivered through SMS, WhatsApp, and RCS for alerts, marketing, one-time passwords, and customer notifications. Growth is driven by e-commerce and banking needs for secure authentication and real-time engagement, with SMS still dominant in spend even as OTT platforms gain volume.

Market dynamics are shaped by security and compliance (2FA, fraud prevention), platform consolidation (CPaaS leaders like Twilio, Sinch, Infobip, Route Mobile), and ongoing regulatory oversight. The market is multi-billion dollar and projected to exceed $90–125B in the early 2030s, with increasing emphasis on AI-driven personalization and channel orchestration.

Least Cost Routing (LCR) is central to A2P SMS economics. Aggregators and carriers use real-time routing to select the cheapest compliant paths, while balancing delivery quality. The industry also contends with grey routes that disguise A2P traffic as P2P to lower costs, which can lead to blocking, lower delivery rates, and fraud exposure.

Arbitrage arises from price gaps between premium “white routes” and lower-cost grey routes. While blended pricing can reduce enterprise costs, it creates revenue leakage for mobile network operators, prompting stronger enforcement and a shift toward verified routes and richer OTT alternatives.

A2P invoicing relies on per-message rating and detailed charging models. CDRs track message metadata (sender IDs, destination networks, delivery status, message type, and charges), enabling accurate billing, 10DLC compliance fees, and pass-through termination charges. Rating, routing, and trading platforms are required to preserve margins across diverse carrier rate decks.

SMS firewalls further shape settlement economics by filtering grey traffic and monetizing legitimate A2P traffic. Operators deploy AI-driven security to detect AIT fraud, enforce sender verification, and ensure only authorized traffic is delivered and billed.

Mudarabah Principles for Traffic Funding

SukukFi applies a Mudarabah structure to fund postpaid traffic while ensuring suppliers are paid and profits are shared transparently:

Capital deployment: The investment vaults (rab al-mal) provide funds to an operating entity (mudarib) on CommTrade to serve a pre-approved debtor (e.g., Tier 1 operator or hyperscaler).
Vendor payments enforced: CommTrade automates supplier payments for the debtor’s traffic while enforcing profitability thresholds.
Real-time profit control: CommTrade validates traffic and margins; unprofitable routes are removed to protect returns.
Profit realization: When the debtor pays the invoice, funds are collected into a SukukFi-controlled fiat account, converted to stablecoins, and distributed back to the investment vault and the mudarib according to the agreed profit split.

Comparison to Traditional Invoice Finance

No interest charged: Returns are based on profit-sharing, not interest on a loan.
Supplier payment focus: Funds are used to pay vendor costs in the transaction chain, rather than advancing a partial percentage of an invoice.
Not collateralized lending: Traditional invoice finance uses the invoice as collateral for a loan; SukukFi structures financing as asset-backed, profit-sharing participation.
Operational enforcement: CommTrade enforces routing and profitability in real time, reducing leakage and ensuring funded traffic remains profitable.
Settlement-grade audit trail: CDR-based validation and smart contract controls provide transparent, verifiable cash-flow tracking.

Use Case 3 - Prepayment Funding for SMS Firewall & Exclusive Termination Deals

Exclusive A2P gateway agreements are increasingly used by mobile network operators to secure their networks, reduce fraud, and monetize international A2P traffic. In these arrangements, a single partner manages and terminates all inbound messaging traffic, replacing fragmented multi-aggregator routing.

Exclusive gateways provide revenue protection by shutting down grey routes, implementing advanced anti-fraud tooling, and enforcing high-quality delivery for OTPs and critical notifications. Many agreements also cover A2P voice/flash calls alongside SMS for omnichannel security and compliance.

SMS firewall gateways sit at the core of this model. They classify traffic in real time, filter spam and phishing, enforce licensed routes, and provide analytics that drive accurate billing. This preserves operator revenues while improving subscriber trust and network performance.

SMS firewall deals typically require the deploying operator to aggregate inbound market traffic, commit to minimum monthly volumes, and prepay for capacity over 6 to 24-month terms.

Use Case 4 - Prepayment Funding for Special Rate Carrier Voice Termination

Carrier voice bilateral agreements define direct, negotiated routes for international voice traffic. These contracts set pricing, volumes, SLAs, and term commitments, allowing operators to control quality and profitability without relying solely on hubs or transit.

Swap deals and special rate agreements are common in wholesale voice. Carriers exchange traffic commitments to unlock better rates, then monetize excess or discounted capacity by selling termination to downstream customers, often with prepayment commitments to secure volume and reduce risk.

These structures enable cost savings and predictable margin planning, while allowing carriers to expand coverage and maintain service quality across high-volume routes.

Murabaha Principles for Prepayment Funding

SukukFi applies a Murabaha financing method to provide operating entities with funding to purchase capacity from suppliers at cost plus a pre-agreed, disclosed markup payable over time.

SukukFi supports prepayments for firewall deployments, exclusive gateway capacity, and special-rate termination without interest-based lending.

Asset-backed structure: Financing is linked to telecom capacity rather than unsecured cash lending.
Direct vendor payment: Funds are paid directly to suppliers to ensure transparency and compliance.
Known profit margin: The uplift is agreed upfront, with clear repayment terms.
Receivable security: SukukFi takes security over the operating entities' debtor receivables and collects debtor payments through its banking infrastructure.

Murabaha vs Traditional Riba-Based Finance

Asset-linked vs cash lending: Murabaha is tied to real assets or capacity; riba-based finance lends cash against interest.
Transparent markup: Profit is disclosed and agreed upfront, instead of compounding interest over time.
Vendor payment certainty: Funds flow directly to suppliers, ensuring delivery and reducing misuse of proceeds.
Sharia compliance: Avoids riba and aligns returns with real economic activity.
Receivable-backed security: Collections are linked to actual customer payments rather than interest schedules.

Use Case 5 - Funding Wireless POTS Deployments in the USA

Wireless POTS replaces legacy copper landlines with LTE/5G or broadband adapters that deliver analog dial tone for critical devices like alarm panels, elevator phones, and fax machines. As carriers retire copper networks and service mandates, businesses are forced to migrate to more reliable, remotely managed digital alternatives.

The migration is driven by rising costs for legacy lines, reduced carrier support, and the need for failover connectivity in life-safety and compliance-critical environments. Wireless POTS deployments typically require the purchase and installation of certified hardware at scale, backed by multi-year service contracts.

Murabaha Principles for Funding Wireless POTS Deployments in USA

SukukFi funds these deployments using Murabaha-based financing tied to the equipment and service contract, with repayment matched to recurring revenue over the contract term.

Contract-linked funding: Financing is structured around recurring revenue agreements, typically over 36 months.
Direct vendor payment: Funds are paid to approved suppliers to procure deployment hardware.
Known profit margin: The cost-plus markup is disclosed upfront with clear repayment terms.
Receivable security: SukukFi secures the contract receivables and collects customer payments through its banking infrastructure.

Sharia conclusion: The structure remains asset-backed and transparent, avoiding riba while keeping funding tied to real economic activity and measurable service delivery.

Comparison to interest-based financing: Unlike loans that charge interest on cash advances, Murabaha financing links returns to tangible equipment and disclosed markups, giving operators predictable costs while aligning funding to delivered capacity and contracted cash flows.

Frequently Asked Questions

General Questions

What is SukukFi?

SukukFi is a global on-chain marketplace where profitable businesses can raise debt from DeFi investors. SukukFi debt instruments are secured against the cash-flow and supply inventory of profitable businesses raising debt. DeFi investors receive yield generated from a share of the profit of the business. SukukFi bridges global trade markets with DeFi infrastructure, unlocking a new asset class and yield opportunity through blockchain-based profit sharing.

How does SukukFi work?

SukukFi connects real world business and commerce with on-chain capital using stablecoins. Starting in the $1T per annum Wholesale Telecom Carrier Industry; SukukFi builds credit lines for telecom related technology companies selling to larger institutional credit-worthy customers on extended payment terms, such as Hyperscalers, Government departments and/or Tier1 Telecom Operators or Mobile Operators. Capital providers deposit stablecoins into pools which are used to pay suppliers and in turn earn a share of the profit generated from selling to credit-worthy customers.

What is a SukukFi Bond?

SukukFi capital providers deposit stablecoins into pools and in doing so receive a token representing their share of the overall pool. This token represents the Bond they have invested in which will earn a share of the profits from the business that raises debt under this bond.

What makes SukukFi different from other DeFi protocols?

SukukFi has embedded its proprietary smart contract infrastructure into the business and operational support systems used by telecom related technology companies to enable trade and commerce.
Smart contract infrastructure secures and controls the flow of money in deal chains involving telecom related technology companies.
Real yield, not token emissions; returns come from actual business profits, not inflationary token models or interest on debt.
Bond composability; SukukFi bond tokens are composable across DeFi allowing for secondary liquidity and use as a collateral asset (e.g. lend/borrow).
Institutional access; designed for DAOs, crypto funds, and qualified investors looking to diversify with low-correlated yield.

Business Questions

Who can raise debt through SukukFi?

Telecom related technology companies involved in trading traffic streams of voice minutes, SMS messaging and/or data through IoT and roaming contracts. If you are technology provider and/or trading in the following industries looking for debt financing or liquidity solutions then we would like to speak with you:

Payments companies and/or subscriber businesses performing remittances
Energy companies involved in the wholesale purchase of electricity and/or gas contracts
Game makers working with game publisher networks and marketplaces
Digital media brands involved in programmatic advertising and social media
Exporters of industrial/precious metals, agricultural/mineral commodities, electronics, machinery and/or automotives
Financial institutions and/or fintechs involved in consumer micro credit, automotive and/or real estate transactions

Investment Questions

Who can invest in SukukFi?

Capital Providers (yield seekers; subject to KYC onboarding) looking for stable, non-correlated returns:
Individual DeFi Investors
Institutional Investors: DAOs, crypto-native funds, accredited investors, and institutional investors
Capital Providers must complete the one-time KYC check before depositing stablecoins in the pools. Once your KYC is verified the smart contract governing the pools will execute the deposit of stablecoins into the pools.

What is the expected return or APY?

We target 10-20% base return equivalent in profit shares for underwriting credit and payment terms to customers when funding supplier terms in our transaction chains. Yields can be boosted by providing liquidity on DeFi AMMs using the bond tokens issued when stablecoins are deposited into pools. Yields will be compounded if investors do not withdraw their liquidity from the pools.

How can I withdraw or exit my position?

SukukFi stablecoin pool smart contracts utilise the ERC-7540 token standard that enables asynchronous interactions with ERC-4626 tokenised vaults. Investors will make requests to withdraw their stablecoins from the pool. If the stablecoins are available to withdraw i.e. the stablecoins have not been used to pay suppliers in a transaction chain, then the smart contract will enforce withdrawal back to the investor's wallet. If the stablecoins are not available to withdraw i.e. the stablecoins have been used to pay suppliers in a transaction chain, then the smart contract will wait until liquidity becomes available to enforce withdrawal back to the investor's wallet; whether that is due to a customer payment or new investors enter the pool. Alternatively, trading on secondary markets such as DeFi AMMs is available 24/7/365 subject to liquidity and allows investors to sell their bond tokens on the open market.

Technical Questions

Which stablecoins can I deposit into SukukFi pools?

SukukFi pools are deployed on Berachain where capital providers can deposit the following stable coins:

USDT0
USDC
BYUSD (PYUSD on Berachain)
HONEY
USDe (Ethena)

If you have stablecoins on any other blockchain you can use bridging providers such as Stargate Finance to transfer your coins to Berachain.

How is yield generated and distributed?

Yield is generated from a share of the profit on transactions that are funded by our proprietary smart contract infrastructure. The SukukFi platform advances liquidity to fund the supplier side deals whilst collecting the revenue from the customer side. At all times, the platform is monitoring the profit margins of the deals and is able to enforce profit shares accordingly. When the customer pays their invoices, the funds are collected on banking infrastructure controlled by the SukukFi platform which exchanges fiat currency into stablecoins to then distribute capital repayments and profit shares back to investors.

How is SukukFi Sharia compliant?

The SukukFi proprietary smart contract infrastructure is hard-coded sharia compliant. The mechanisms deployed for funding transactions in deal chains are based on the following Islamic Finance principles: Mudarabah is a profit-sharing contract where one party provides capital in conjunction with an entrepreneur who runs the business venture. Profits are shared according to a pre-agreed ratio, while losses are borne by the capital provider. Murabaha is a sale contract where a capital provider buys an asset and then resells it to a customer at a predetermined price that includes a profit margin agreed upon upfront. It is a cost-plus financing method, meaning the profit is known and fixed at the time of the agreement, rather than being interest-based like in conventional finance. SukukFi smart contracts are open to everyone including non-muslims and our philosophy of wealth building is on the basis of profit participation from revenue-generating businesses.

Contact & Support

Get in Touch

CEO: ceo@sukuk.fi ✉

Business Development: bd@sukuk.fi ✉

Technical Support: dev@sukuk.fi ✉

Community Links

Website: https://sukuk.fi ↗

Application: https://app.sukuk.fi ↗

Twitter: https://x.com/sukukfi ↗

LinkedIn: https://www.linkedin.com/company/sukukfi ↗

📚 SukukFi Documentation

Overview

Getting Started

Welcome to SukukFi

Quick Start Guide

Understanding SukukFi

What is SukukFi?

How SukukFi Works

Why SukukFi is Different

Products

SukukFi Bond Pools

SukukFi Bond Tokens

Supported Industries

Current Focus: Wholesale Telecom Carrier Industry

Expansion Industries

For Capital Providers

Who Can Invest

Investment Process

Supported Assets

Expected Returns

Risk Considerations

For Businesses

Eligibility Criteria

Benefits for Businesses

Technical Infrastructure

System Purpose

Multi-Tier System Architecture

Complete Ecosystem Overview

Layer-by-Layer Breakdown

TIER 1: Telecom OSS/BSS Systems

TIER 2: COMMTRADE Platform (Off-Chain Smart Contract Engine)

TIER 3: WRAPX Platform (Off-Chain Settlement Entity)

TIER 4A: On-Chain Settlement Layer (WERC7575)

Use Case Flow

Key Design Rationale: Settlement Layer

1. Permissionless Deposits (with KYC)

2. Dual Authorization for Withdrawals

3. Batch Settlement Optimization

4. rBalance System for Investment Tracking

TIER 4B: Investment Layer (Upgradeable)

Use Case Flow

Key Design Rationale: Investment Layer

1. Async Operations (ERC-7540)

2. Investment into Settlement Contract

3. Upgradeable Architecture

System Interaction: Two Layers Working Together

Capital Flow

Yield Generation Mechanism

Example: End-to-End Flow

Why Two Separate Systems?

Separation of Concerns

Why Settlement is Non-Upgradeable

Why Investment is Upgradeable

Centralization Rationale in Context

Settlement Layer Centralization

Investment Layer Centralization

Security Considerations in Context

Settlement Layer Security Priorities

Investment Layer Security Priorities

Integration Notes for Auditors

Understanding Context is Critical

What Makes This Different from DeFi

Conclusion

Liquidity & Redemption

Withdrawal Process

Secondary Market Liquidity

Sharia Principles

Core Prohibitions

Positive Requirements

Common Shariah-Compliant Structures

Mudarabah (profit-sharing partnership)

Musharakah (joint venture)

Murabaha (cost-plus sale)

Ijara (lease)

Sukuk (asset-based certificates)

Takaful (mutual insurance)

Governance and Oversight

How SukukFi Aligns

Risk Management

Business Risk Assessment