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 top up wallets around the clock and cannot wait for manual approval
- KYC gates entry, so deposits themselves need no extra permission
- A deployed telecom integration confirms carrier identity
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?
- Open disputes must close before a carrier can withdraw
- Fraud investigations require funds to stay locked
- AML checks gate large withdrawals
- Carriers must keep enough liquidity to cover ongoing settlements
- The 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?
The transfer needs dual authorization:
- 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:
- The platform blocks unauthorized withdrawals while carriers delegate to trusted third parties
- Smart contracts can participate once the platform approves
- Platform limits and carrier-set limits are independent, so each can be sized separately
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 settle each month; batching keeps costs manageable
- Netting: Circular debts (A owes B, B owes C, C owes A) collapse to a single net transfer
- Atomic Settlement: All transfers succeed together or all revert, preventing partial settlement
- Regulatory Audit Trail: One on-chain transaction covers a full 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: The investment contract deploys capital into telecom deals and needs a separate counter for funds in play
- Yield Distribution: When deals close profitably, the platform adjusts rBalance to record returns
- Liquidity Management: Separates funds available for new deals from capital locked in existing ones
- Regulatory Reporting: Liquid funds and invested capital appear as distinct line items
Note: Carriers do not get rBalance tracking. Only the investment contract (ShareTokenUpgradeable) uses rBalance to track 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 the 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 duPRT shares
Step 2: Investment Deployment
──────────────────────────────
Investment Manager takes vault's idle USDC and invests:
investAssets(amount) → deposits into WERC7575Vault (Settlement Layer)
WERC7575Vault mints settlement position to ShareTokenUpgradeable (internal)
ShareTokenUpgradeable holds settlement backing 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 duPRT 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: The Investment Manager batches deposits when suitable deals appear
- Liquidity Management: Instant execution is not required; queuing deposits preserves flexibility
- Risk Management: The Investment Manager can delay fulfillment 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 earn yield from real telecom settlements, not synthetic products
- Transparent: Capital flows into the operational contract with a clear on-chain record
- Measurable: The settlement position tracks on-chain through the internal layer
- Liquid: The Investment Manager withdraws from settlement when needed, subject to permit approval
3. Upgradeable Architecture
contract ERC7575VaultUpgradeable is UUPSUpgradeable, OwnableUpgradeable
Why?
- Regulatory Adaptation: Investment products change with compliance requirements
- Feature Additions: New investment strategies slot in without redeploying the settlement layer
- Bug Fixes: Patches apply without migrating carrier funds
- Separation of maturity: The settlement layer is battle-tested and stays fixed; the investment layer evolves independently