Design Rationale
Understanding why RedCarpetHQ is designed the way it is helps you make better decisions as a producer. This document explains the business logic and reasoning behind key platform features.
Core Philosophy
Decentralization + Quality Control
The Challenge:
Our Solution: Hybrid Approach
Why This Works:
Token-Based Crowdfunding
Why Tokens Instead of Traditional Rewards?
Traditional crowdfunding (Kickstarter, Indiegogo):
Token-based crowdfunding (RedCarpetHQ):
Benefits for Producers:
Benefits for Supporters:
Campaign Mechanics
Floor & Ceiling Model
Why Not Fixed Goal?
Floor (Minimum):
Ceiling (Maximum):
Overage Options:
Real-World Example:
``
Film Budget: $100k minimum, $300k ideal
Floor: $100k (can make film)
Ceiling: $300k (ideal production value)
Overage: Ceiling type
Result:
`
Grace Period (24 Hours)
Why Not End Immediately?
Problems Without Grace Period:
Campaign ends at random moment
Last-minute backers miss deadline
No time to assess near-misses
Harsh for 99% funded campaigns
Grace Period Benefits:
Creator can extend if close
Supporters can push final stretch
Fair assessment window
Reduces "just missed it" frustration
Why 24 Hours?
Long enough to decide
Short enough to maintain urgency
Prevents indefinite limbo
Industry standard
Creator Finalize Grace Period (2 Weeks)
Why Not Auto-Finalize Success?
Creator Needs Time To:
Assess if they can deliver
Review final backer list
Confirm legal compliance
Prepare for production
Decide to proceed or refund
Why 2 Weeks?
Reasonable decision window
Consult with team/lawyers
Not too long (supporters waiting)
After 2 weeks, anyone can finalize
Protects Everyone:
Creators: No forced commitment
Supporters: Campaign won't stay in limbo
Platform: Prevents stalled campaigns
Extension Limits
Why Only 1 Extension?
Without Limits:
❌ Campaigns drag on indefinitely
❌ Supporter fatigue
❌ Looks desperate
❌ Reduces urgency
With 1 Extension:
✅ Second chance for near-misses
✅ Maintains urgency
✅ Prevents abuse
✅ Clear boundaries
Maximum Duration (270 Days):
9 months total maximum
Prevents zombie campaigns
Keeps platform active
Forces decision making
DeFi Architecture
ERC4626 Vaults (UnifiedVault)
Why ERC4626 Standard?
Benefits:
Industry-standard interface
Compatible with all DeFi tools
Auto-integrates with aggregators
Wallets show balances automatically
Composable with other protocols
Why One Vault Per Token?
Old Approach (5 Contracts):
❌ Complex architecture
❌ Gas-intensive
❌ Hard to audit
❌ Difficult to understand
New Approach (1 Contract):
✅ Simple architecture
✅ Gas-efficient
✅ Easy to audit
✅ User-friendly
80/20 Deposit Split
Why Not 100% Lending?
Problem:
Liquidations need USDC immediately
External liquidators slow/unreliable
Gas wars during liquidations
Bad debt risk
Solution: Stability Pool (20%)
Instant liquidation USDC available
No external liquidators needed
Automatic process
Protects lenders
Why 80/20 Ratio?
80% lending = good capital efficiency
20% stability = adequate liquidation buffer
Balanced approach
Tested in other protocols (Liquity)
User Experience:
`
Deposit: 1,000 USDC
Automatically allocated:
800 USDC → Lending Pool (earn interest)
200 USDC → Stability Pool (liquidation buffer)
User sees: 1,000 vault shares
Complexity hidden, benefits automatic
`
Risk-Tiered Interest Splits
Why Not Fixed Interest Split?
Problem:
Market conditions change
Some tokens riskier than others
Fixed split doesn't adapt
Risk not priced correctly
Solution: Dynamic Tiers
| Tier | Protocol | Insurance | Lenders | When |
|------|----------|-----------|---------|------|
| GREEN | 4% | 6% | 90% | Healthy market |
| YELLOW | 6% | 9% | 85% | Moderate risk |
| RED | 10% | 15% | 75% | High risk |
Why This Works:
Green: Low risk = lenders get most
Yellow: Medium risk = more to insurance
Red: High risk = much more to insurance + protocol
Risk Factors Assessed:
Price staleness
Vault utilization
Wash trading
Market health
Dispute activity
Benefits:
Automatic risk adjustment
Insurance fund grows when needed
Lenders protected
Protocol sustainable
Collateral Factors & Liquidation
Why 50% Collateral Factor (Green)?
Too High (e.g., 90%):
❌ High liquidation risk
❌ Small price drops = liquidation
❌ Bad debt risk
❌ Lender losses
Too Low (e.g., 20%):
❌ Capital inefficient
❌ Low borrowing utility
❌ Unattractive to users
50% Sweet Spot:
✅ Safe buffer
✅ Reasonable utility
✅ Industry standard
✅ Proven in DeFi
Liquidation Threshold (60%):
10% buffer above collateral factor
Gives time to add collateral
Prevents immediate liquidation
Fair warning system
Example:
`
Deposit: 100 tokens @ $10 = $1,000
Borrow: $500 (50% collateral factor)
Price drops to $8.33:
Collateral value: $833
Borrowed: $500
Ratio: 60% (liquidation threshold)
Position liquidated
Buffer: $1,000 → $833 = 16.7% price drop allowed
`
Utilization Cap (85%)
Why Not 100% Utilization?
Problem:
100% utilized = no withdrawals possible
Bank run risk
Lenders trapped
System instability
85% Cap:
✅ Always 15% available for withdrawals
✅ Prevents bank runs
✅ Maintains liquidity
✅ Protects lenders
Interest Rate Curve:
`
0-70%: Gradual increase (optimal range)
70-85%: Steep increase (discourage borrowing)
85%+: No borrowing allowed
`
Why This Works:
Low utilization = low rates (encourage borrowing)
High utilization = high rates (encourage repayment)
Cap = safety valve
Self-balancing system
Trading & Markets
Escrow-Based Trading
Why Not Order Book?
Order Book Problems:
Complex to implement
Gas-intensive
Front-running risk
MEV exploitation
Escrow Offers:
✅ Simple and secure
✅ Gas-efficient
✅ No front-running
✅ Funds locked safely
How It Works:
`
Seller creates offer:
1. Locks tokens in Market contract
2. Sets price
3. Waits for buyer
Buyer fills offer:
1. Sends USDC to Market
2. Market sends tokens to buyer
3. Market sends USDC to seller
4. Atomic swap (all or nothing)
`
VWAP Price Oracle
Why VWAP Instead of Last Price?
Last Price Problems:
❌ Easy to manipulate
❌ Single trade affects price
❌ Wash trading exploits
❌ Not representative
VWAP Benefits:
✅ Volume-weighted (manipulation harder)
✅ Reflects true market activity
✅ Smooths out anomalies
✅ Fair liquidation pricing
Formula:
`
VWAP = Σ(Price × Volume) / Σ(Volume)
`
Example:
`
Trade 1: 100 tokens @ $10 = $1,000
Trade 2: 50 tokens @ $12 = $600
Trade 3: 200 tokens @ $9 = $1,800
VWAP = ($1,000 + $600 + $1,800) / (100 + 50 + 200)
= $3,400 / 350
= $9.71
Fair price despite $12 outlier
`
Trading Contests (6-Hour Epochs)
Why Trading Contests?
Goals:
Incentivize trading activity
Reward active traders
Create engagement
Distribute fees fairly
Why 6 Hours?
❌ Too short (1 hour): Not enough activity
❌ Too long (24 hours): Reduces urgency
✅ 6 hours: Perfect balance
4 epochs per day:
Multiple chances to win
Global time zone coverage
Maintains excitement
Sustainable participation
15,000 USDC Threshold:
Prevents sybil attacks
Ensures serious traders
Meaningful qualification
Protects prize pool
Pro-Rata Distribution:
`
Trader A: 50,000 USDC volume
Trader B: 30,000 USDC volume
Trader C: 20,000 USDC volume
Total: 100,000 USDC volume
Prize Pool: 1,000 USDC
Trader A: 500 USDC (50%)
Trader B: 300 USDC (30%)
Trader C: 200 USDC (20%)
Fair distribution by contribution
``
2.5% Trade Fee
Why Charge Fees?
Platform Sustainability:
Why 2.5%?
Fee Distribution (40/40/10/10):
Why This Split?
Revenue Distribution
Dividend System
Why Dividends?
Traditional Film Financing:
Blockchain Dividends:
Snapshot-Based:
Multi-Round Support:
Producer Exit Strategy
Why Allow Producer Exit?
Problem:
Solution: Burn for Vault Shares
Requirements:
Why This Works:
Security & Risk Management
Circuit Breakers
Why Automatic Pauses?
Triggers:
Purpose:
Why These Thresholds?
Wash Trading Detection
Why Monitor Wash Trading?
Problem:
Detection:
Consequences:
Reentrancy Protection
Why Needed?
Famous Attacks:
Our Protection:
Platform Investor Perspective
Why This Architecture Creates Defensibility
For investors evaluating RedCarpetHQ as a protocol or business, our design choices are not just engineering preferences — they are competitive moats.
The Fee Model as a Flywheel
Our 40/40/10/10 fee split is designed to be self-sustaining:
Traditional exchanges spend millions on market maker programs. We recycle our own fees into trader incentives.
Zero Campaign Fees as Customer Acquisition
By not charging producers to raise, we remove the #1 barrier to listing:
AI Risk Oracle as Scalable Compliance
Manual due diligence does not scale. Our RiskOracleV3 enables:
ERC-4626 as Distribution
By building on the ERC-4626 standard, we gain distribution automatically:
Why Testnet-First Is Capital Efficient
We have iterated through three major contract architectures (V1 → V2 → V3) on testnet before mainnet:
Platform Evolution
Why Unified Architecture?
V1/V2 Problems:
Architecture Improvements:
Benefits:
Testnet First
Why Testnet First?
Before Mainnet:
Mainnet Launch:
Next Steps: Understand Campaign Economics →