Architecture Overview
TicketKiosk Contract
Primary Functionality
Each TicketKiosk manages ERC721 ticket sales for its specific event:Deployment Process
TicketKiosks are deployed using CREATE2 for deterministic addresses:Ticket Purchase Flow
Revenue Distribution Model
TicketKiosk implements immediate revenue distribution on purchase:Ticket Naming Convention
Tickets follow a standardized naming pattern for easy identification:Metadata Synchronization
TicketKiosks maintain synchronization with their parent event’s metadata:Curation Contract
Service Provider Integration
Curation contracts enable third-party service providers to monetize event support:Scope-Based Fee Structure
Curation fees are determined by service scope:| Scope | Role | Fee Rate | Description |
|---|---|---|---|
| 1 | Planner | 3% | Event planning and coordination |
| 2 | Promoter | 7% | Marketing and audience development |
| 3 | Producer | 10% | Full production and technical support |
Deployment and Registration
Revenue Flow Integration
Curation Configuration Management
Event creators can configure curation parameters before the event starts:Deterministic Address Generation
CREATE2 Implementation Benefits
Both TicketKiosk and Curation contracts use CREATE2 deployment: Advantages:- Predictable Addresses: Frontend can compute addresses before deployment
- Gas Efficiency: No need for registry lookups
- Consistency: Same salt formula across all deployments
- Security: Prevents address manipulation attacks
Event-Specific State Management
Isolated Storage Context
Each per-event contract maintains independent state: TicketKiosk State:- Ticket inventory and sales tracking
- Revenue distribution history
- Event-specific metadata cache
- User ticket ownership mapping
- Service provider configuration
- Earnings and withdrawal tracking
- Scope and fee parameters
- Service activation status
Cross-Contract Communication
Per-event contracts integrate with the protocol ecosystem:Gas Optimization Strategies
Deployment Cost Analysis
| Contract Type | Deployment Gas | Runtime Gas/Call | Use Case |
|---|---|---|---|
| TicketKiosk | ~2,500,000 gas | Standard | Always deployed |
| Curation | ~1,800,000 gas | Standard | Optional deployment |
| Total per Event | ~4,300,000 gas | - | Full feature set |
Storage Optimization
TicketKiosk Packing:Design Advantages
Per-Event Isolation
- Independent Lifecycle: Each event manages its own state
- Customizable Parameters: Event-specific configurations
- Isolated Risk: Problems in one event don’t affect others
- Parallel Processing: Multiple events can operate simultaneously
- Clear Ownership: Each contract has a single responsible creator
Modular Revenue Streams
- Immediate Distribution: Ticket sales distribute funds instantly
- Deferred Distribution: Tips accumulate for later distribution
- Service Integration: Curation provides third-party monetization
- Transparent Tracking: All revenue flows are recorded on-chain
- Flexible Fee Structures: Different rates for different service levels
Limitations
- CREATE2 deployment requires salt management.
- Failed deployments waste gas, deployment script needs refinement.
- Difficult to upgrade individual event contracts, altough modular, contracts are strictly interdependent.
- No mechanism for dispute resolution in service provider conflicts, as mentioned elsewhere, this will be resolved through protocol-wide, enforceable governance (community-led dispute resolution and multi-sigs).