DeFi has unlocked powerful financial primitives-lending, borrowing, and yield generation-without intermediaries, using stablecoins. But most DeFi systems are fully permissionless, making them difficult for adoption in regulated environments.
Institutions need:
Identity verification (KYC)
Controlled access
Regulatory compliance
So, the real challenge is: Can we retain the efficiency of DeFi while meeting the many necessary institutional requirements?
This is exactly where permissioned lending pools come in.
What cSigma is Building?
cSigma is building a system where participation in lending pools is restricted to verified users, while keeping the core benefits of decentralized systems in place.
Unlike traditional DeFi:
Access is controlled
Participation requires verification
Unlike traditional finance:
Funds remain non-custodial
Rules are enforced on chain
Transparency is preserved
Our infrastructure is designed to be chain-agnostic and is already deployed across both EVM-compatible networks and Hedera.
How does the system work?
The system is composed of three layers:
Web Application → User interaction
Backend Services → KYC, eligibility, and data synchronization
On-chain Logic (smart contracts / native services) → Fund management and enforcement
User Flow
The typical user onboarding steps are below-
User registers via the web app
Completes KYC verification
Backend validates eligibility
Wallet is whitelisted
User deposits into a pool
Receives LP (liquidity provider) tokens
Withdraws funds (instant or queued based on liquidity)
Access Control: Layered by Design
Access is enforced across multiple layers:
Layer | Responsblity |
|---|---|
KYC | Identity verification |
Backend | Eligibility decision |
On-chain logic | Final enforcement |
UI | User guidance |
Even if the UI or backend fails, on-chain enforcement remains the final authority.
Whitelisting: Controlled Participation
Pool managers alone have the right to define who can participate. Their key capabilities include:
Add/remove lenders (single/ batch)
Support multiple wallet addresses for a single user
Maintain on-chain whitelist
If a wallet is not whitelisted, it simply cannot interact with the pool.
Deposits and Withdrawals
A single module handles both flows.
Deposits
User submits funds
LP tokens are minted
Tokens represent ownership in the pool
Withdrawals
This is where things get interesting.
Withdrawals can be instant or queued, depending on available liquidity:
If sufficient funds are available in the pool’s reserve, the withdrawal is processed instantly.
If funds are already deployed, the request enters a withdrawal queue.
Queued withdrawals are fulfilled as repayments are made back into the pool. This design balances user experience with realistic capital deployment.
Why a Withdrawal Queue?
In real-world lending, capital is actively deployed, not sitting idle. Instead of assuming instant liquidity, we introduce a queue mechanism that releases funds based on a repayment cycle. Ultimately, creating a more accurate and sustainable liquidity model.
Repayments: How Lenders Get Paid?
Pool managers can repay lenders in two ways:
Non-Proportional
Pay specific wallets
Custom repayment amounts
Proportional
Enter total repayment amount
The system is distributed based on LP ownership
During repayment, funds are transferred, LP tokens are burnt, and balances are updated.
LP Tokens: The Accounting Layer
Each deposit generates LP tokens. These tokens represent ownership share, track outstanding value, and enable accurate repayment distribution. They act as the backbone of accounting within the system.
Scaling with Sub Pools
The system supports multiple sub-pools under a master pool. The Benefits include better risk segmentation, independent pool management, and flexible repayment structures. For variable pools, performance data must be reported before repayments.
Keeping Everything in Sync
Blockchain data requires indexing for application use.
A backend scheduler runs periodically, syncs pool state, transaction & whitelist data.
This ensures UI consistency, real-time data representation, and reliable access control.
Performance Optimization
To improve user experience:
Transaction data is cached locally
Cached data loads instantly
Refresh occurs only when necessary
This reduces latency and unnecessary API calls, increasing speed.
Multi-Chain Compatibility
Our infrastructure is designed to be chain-agnostic. While core implementations exist on EVM, the same architecture can be extended to Hedera.
Key considerations include:
Identity and whitelist enforcement
Token standards and accounting models
Transaction finality and cost structure
This allows the platform to operate across ecosystems without changing core principles.
Key Design Decisions
Non-custodial architecture-Funds are managed on chain, not by the backend
Off-chain KYC-Sensitive user data remains private
On-chain enforcement rules cannot be bypassed
Controlled liquidity-Withdrawal queues reflect real-world constraints
Batch operations-Efficient multi-user transactions
Final Thoughts
This system sits at the intersection of two worlds: The efficiency and transparency of DeFi and the control and compliance of traditional finance
It delivers permissioned access, tokenized lending, structured repayments, and realistic liquidity management. All while maintaining non-custodial fund control and on-chain enforcement.
As DeFi evolves, systems like this will play a key role in enabling adoption across both EVM ecosystems and networks like Hedera.