# 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:**
- Pure decentralization = anyone can create campaigns (spam risk)
- Pure centralization = gatekeeping, censorship, single point of failure

**Our Solution: Hybrid Approach**
- **Screener Whitelist**: Quality control without centralization
- **Multiple Screeners**: Distributed trust, no single gatekeeper
- **Toggle Option**: Can disable screening if community prefers
- **On-Chain Operations**: All funds and logic on blockchain

**Why This Works:**
- Protects supporters from scams
- Maintains platform reputation
- Preserves decentralization benefits
- Flexible for future evolution

### Token-Based Crowdfunding

**Why Tokens Instead of Traditional Rewards?**

Traditional crowdfunding (Kickstarter, Indiegogo):
- ❌ No secondary market
- ❌ Backers locked in
- ❌ No financial upside
- ❌ Reward fulfillment burden

Token-based crowdfunding (RedCarpetHQ):
- ✅ Tradable on marketplace
- ✅ Exit opportunities
- ✅ DeFi utility (lending, borrowing)
- ✅ Dividend participation
- ✅ Liquid market for price discovery

**Benefits for Producers:**
- Attract investment-minded backers
- Token liquidity increases appeal
- DeFi features add value
- Easier than physical reward fulfillment

**Benefits for Supporters:**
- Trade tokens anytime
- Earn yield through lending
- Participate in film success
- Portfolio diversification

## Campaign Mechanics

### Floor & Ceiling Model

**Why Not Fixed Goal?**

**Floor (Minimum):**
- Ensures project viability
- All-or-nothing reduces risk
- Protects both sides
- Clear success criteria

**Ceiling (Maximum):**
- Prevents over-dilution
- Manages token supply
- Sets realistic expectations
- Controls project scope

**Overage Options:**
- **No Overage**: Fixed budget projects
- **Unlimited**: Flexible scope
- **Ceiling**: Budget range

**Real-World Example:**
```
Film Budget: $100k minimum, $300k ideal

Floor: $100k (can make film)
Ceiling: $300k (ideal production value)
Overage: Ceiling type

Result:
- Must reach $100k to proceed
- Can accept up to $300k
- Clear budget boundaries
- Token supply capped
```

### 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:**
- Development costs
- Infrastructure
- Security audits
- Support team
- Marketing

**Why 2.5%?**
- ❌ Too low (<1%): Unsustainable
- ❌ Too high (>5%): Discourages trading
- ✅ 2.5%: Industry standard, fair

**Fee Distribution (40/40/10/10):**
- **40% Protocol**: Platform development
- **40% Contest**: Trader rewards
- **10% Vault**: Protocol's allocation
- **10% Producer**: Creator rewards

**Why This Split?**
- Traders get most back (40% + vault returns)
- Producers incentivized (10%)
- Platform sustainable (40%)
- Balanced ecosystem

## Revenue Distribution

### Dividend System

**Why Dividends?**

**Traditional Film Financing:**
- Complex waterfall structures
- Opaque accounting
- Delayed payments
- High overhead

**Blockchain Dividends:**
- ✅ Transparent on-chain
- ✅ Instant distribution
- ✅ Pro-rata fairness
- ✅ Low overhead

**Snapshot-Based:**
- Captures holders at specific time
- Prevents gaming system
- Fair to all holders
- Includes vault depositors

**Multi-Round Support:**
- Film revenues over time
- Multiple distributions
- Flexible timing
- Ongoing engagement

### Producer Exit Strategy

**Why Allow Producer Exit?**

**Problem:**
- Producers want to cash out
- Selling tokens dumps price
- Hurts other holders
- Creates conflict

**Solution: Burn for Vault Shares**
- Producer burns tokens
- Receives protocol's vault allocation
- No market impact
- Fair value exchange

**Requirements:**
- Minimum 10 USDC threshold
- 25% exit fee
- Only protocol's allocation
- Doesn't affect other holders

**Why This Works:**
- Producer gets liquidity
- No price dump
- Fee protects ecosystem
- Sustainable exit path

## Security & Risk Management

### Circuit Breakers

**Why Automatic Pauses?**

**Triggers:**
- Bad debt > $10,000
- Utilization > 99%
- Price stale > 12 hours

**Purpose:**
- Prevent cascading failures
- Protect user funds
- Allow admin intervention
- Emergency stop

**Why These Thresholds?**
- Tested in production
- Balance safety vs. false alarms
- Industry best practices
- Adjustable if needed

### Wash Trading Detection

**Why Monitor Wash Trading?**

**Problem:**
- Fake volume manipulation
- Contest exploitation
- False price signals
- Unfair rewards

**Detection:**
- Same-pair trade tracking
- Unique participant counting
- Epoch-based analysis
- Risk tier adjustment

**Consequences:**
- Elevated to YELLOW/RED tier
- Higher insurance allocation
- Lower collateral factors
- Contest disqualification

### Reentrancy Protection

**Why Needed?**

**Famous Attacks:**
- The DAO hack (2016)
- $60M stolen
- Ethereum hard fork

**Our Protection:**
- ReentrancyGuard on all functions
- Checks-Effects-Interactions pattern
- State updates before external calls

## 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:
- **40% to Contests** incentivizes trading volume
- **More volume** generates more trading fees
- **More fees** grow the contest pool, attracting more traders
- **Result**: A self-reinforcing liquidity engine that requires no external subsidy

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:
- Producers flock to the platform with the lowest cost of capital
- More campaigns = more tokens = more trading pairs
- More trading pairs = more volume = more fee revenue
- **Result**: Network effects without burning cash on acquisition

**AI Risk Oracle as Scalable Compliance**

Manual due diligence does not scale. Our RiskOracleV3 enables:
- Exponential token listings without proportional staffing
- Automatic parameter adjustment (no governance votes for every token)
- Real-time protection that reacts faster than any human committee
- **Result**: We can onboard 10x more projects than a manually-screened platform

**ERC-4626 as Distribution**

By building on the ERC-4626 standard, we gain distribution automatically:
- Zapper, DeBank, and other aggregators display our vaults without custom integration
- Wallets show balances natively
- DeFi strategists can compose our vaults into larger yield strategies
- **Result**: Every new ERC-4626 integrator becomes a distribution channel for free

**Why Testnet-First Is Capital Efficient**

We have iterated through three major contract architectures (V1 → V2 → V3) on testnet before mainnet:
- Bugs found cost $0 in user funds
- Gas optimizations tested under realistic conditions
- RiskOracle parameters tuned with real trade data
- **Result**: When we launch mainnet, we are operationally mature, not experimentally naive

## Platform Evolution

### Why Unified Architecture?

**V1/V2 Problems:**
- Too many contracts (5 per token)
- Complex fee routing
- Gas inefficient
- Hard to maintain

**Architecture Improvements:**
- 1 contract per token (UnifiedVault)
- Central FeeDistributor
- Native ERC4626
- Simplified logic

**Benefits:**
- 60% gas savings
- Easier audits
- Better UX
- Future-proof

### Testnet First

**Why Testnet First?**

**Before Mainnet:**
- ✅ Test all features
- ✅ Find bugs safely
- ✅ Gather feedback
- ✅ Iterate quickly
- ✅ No real money risk

**Mainnet Launch:**
- After thorough testing
- Security audits complete
- Community feedback incorporated
- Proven stability

---

**Next Steps:** [Understand Campaign Economics →](business-logic/campaign-economics.md)