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

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)

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)

┌─────────────────────────────────────────────────────────────────────┐
│                    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

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:

1. 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
2. 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)

┌─────────────────────────────────────────────────────────────────────┐
│                    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

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