Creator Direct

Direct fan-to-creator subscriptions with zero platform fees.

Comment

Building CreatorDirect: A Zero-Fee Subscription Platform on Astar

Introduction

In today's creator economy, platforms take significant cuts from creator earnings—often 20-30% or more. CreatorDirect challenges this model by enabling direct fan-to-creator subscriptions with zero platform fees using blockchain technology.

This blog post explains the technical approach, design decisions, and lessons learned while building CreatorDirect on the Astar network using ink! smart contracts.

The Problem

Traditional subscription platforms (Patreon, OnlyFans, Substack) have several issues:

  1. High Fees: Platforms take 5-30% of creator revenue
  2. Payment Delays: Creators wait weeks for payouts
  3. Centralized Control: Platforms can ban creators arbitrarily
  4. Geographic Restrictions: Not all payment methods work globally
  5. Privacy Concerns: Platforms track all user data

The Solution: Blockchain-Native Subscriptions

CreatorDirect uses smart contracts to enable:

  • Direct Payments: Fans pay creators directly, no intermediary
  • Instant Access: Subscription status updates in seconds
  • Zero Platform Fees: Only blockchain transaction costs (minimal)
  • Censorship Resistant: No one can ban or deplatform creators
  • Global Access: Anyone with a wallet can subscribe
  • Transparent: All transactions are on-chain and verifiable

Technical Architecture

Why Astar?

We chose Astar Network for several reasons:

  1. ink! Support: Native WASM smart contract execution
  2. Low Fees: Transaction costs are minimal (< $0.01)
  3. Fast Finality: ~12 second block times
  4. Polkadot Ecosystem: Access to cross-chain functionality
  5. Developer Friendly: Excellent documentation and tooling
  6. Active Community: Strong support for builders

Smart Contract Design (ink!)

The core contract is written in Rust using the ink! framework. Here's the high-level design:

#[ink(storage)]
pub struct CreatorDirect {
    creator: AccountId,              // Who receives payments
    price_per_period: Balance,        // Subscription cost
    period_in_blocks: u32,           // Duration in blocks
    expiry: Mapping<AccountId, u32>, // Subscriber expiry times
    has_pass: Mapping<AccountId, bool>, // Access tracking
    name: String,
    description: String,
}

Key Design Decisions:

1. Time-Based Subscriptions Using Blocks

Instead of calendar time, we use block numbers:

  • More reliable on-chain
  • No dependency on external oracles
  • Predictable with ~12s block time
  • Easy to calculate expiry
let periods: u32 = (transferred / price_per_period) as u32;
let added_blocks = period_in_blocks.saturating_mul(periods);
let new_expiry = base.saturating_add(added_blocks);

2. Flexible Period Purchases

Users can buy multiple periods at once:

  • Pay for 1 month, 6 months, or any multiple
  • Automatic calculation based on payment amount
  • No need for recurring transaction setup

3. Subscription Extension Logic

Smart renewal logic preserves remaining time:

let current_expiry = self.expiry.get(caller).unwrap_or(0);
let base = if current_expiry > now { 
    current_expiry  // Extend from current expiry
} else { 
    now            // Start fresh if expired
};

This means:

  • Early renewal doesn't lose unused time
  • Late renewal starts from current block
  • Users control their renewal timing

4. Creator-Only Functions

Only the contract creator can:

  • Withdraw accumulated funds
  • Update pricing parameters
fn ensure_creator(&self) -> Result<(), String> {
    if self.env().caller() != self.creator {
        Err(String::from("Only creator"))
    } else { 
        Ok(()) 
    }
}

5. Payable Subscription Function

The subscribe function accepts native token payments:

#[ink(message, payable)]
pub fn subscribe(&mut self) -> Result<(u32, u32), String> {
    let transferred = self.env().transferred_value();
    // Calculate periods and update expiry
}

Frontend Architecture (React + Polkadot.js)

The frontend is a single-page React application that:

  1. Connects to Wallets:

    • Uses Polkadot.js Extension
    • Supports multiple accounts
    • Secure signing (keys never leave wallet)

  2. Interacts with Contracts:

    • Loads contract ABI from metadata
    • Constructs transactions
    • Queries contract parameters

  3. Subscription Payment:

    • Simple payment amount input
    • Subscribe function with transaction signing
    • Transaction status feedback

Key Frontend Features:

Progressive Enhancement

Start with wallet connection, then load contract:

// Step 1: Connect wallet
const accounts = await web3Accounts()
setAllAccounts(accounts)

// Step 2: Connect to blockchain
const wsProvider = new WsProvider(SHIBUYA_WS)
const api = await ApiPromise.create({ provider: wsProvider })

// Step 3: Load contract
const contract = new ContractPromise(api, metadata, contractAddress)

Contract Interaction

Query contract parameters:

const { result, output } = await contract.query.getParams(account, { gasLimit })
// Display price, period, and creator information

Payment and Subscription

Simple subscription flow:

await contract.tx.subscribe({ value, gasLimit })
  .signAndSend(account, (result) => {
    if (result.status.isFinalized) {
      // Subscription complete
    }
  })

Development Process

Testing Strategy

We implemented comprehensive testing at multiple levels:

1. Unit Tests (11 test cases)

  • Basic functionality (initialization, subscription)
  • Edge cases (insufficient funds, expired subscriptions)
  • Access control (creator-only functions)
  • Subscription logic (renewals, multi-period)

Example test:

#[ink::test]
fn subscription_expiry_check() {
    // Subscribe for 1 period
    // Advance blocks beyond expiry
    // Verify subscription is inactive
}

2. Integration Testing

Manual testing covered:

  • Wallet connection flow
  • Contract interaction
  • Transaction signing
  • UI state updates
  • Error handling

3. Real Network Testing

Deployed to Shibuya testnet for:

  • Live blockchain interaction
  • Gas cost analysis
  • Block time verification
  • Multi-user testing

Challenges and Solutions

Challenge 1: Block Time Uncertainty

Problem: Block times can vary slightly Solution: Use conservative estimates and show approximate time remaining

Challenge 2: Gas Optimization

Problem: Complex calculations increase gas costs Solution: Simplify logic, use efficient data structures (Mapping instead of Vec)

Challenge 3: UX for Blockchain Newcomers

Problem: Web3 concepts are confusing (wallets, signing, gas) Solution:

  • Clear onboarding instructions
  • Helpful error messages
  • Visual feedback for all actions
  • Progress indicators during transactions

Challenge 4: Metadata Management

Problem: Frontend needs contract ABI Solution:

  • Include metadata.json in frontend build
  • Version metadata with contract deployments
  • Clear documentation for updating

Performance Characteristics

Gas Costs (Shibuya Testnet)

Operation Gas Cost USD Equivalent*
Subscribe ~0.001 SBY ~$0.0001
Check Status Free (query) $0
Withdraw ~0.001 SBY ~$0.0001
Update Params ~0.001 SBY ~$0.0001

*Approximate, varies with token price

Transaction Speed

  • Submission: Instant
  • Confirmation: ~12 seconds (1 block)
  • Finality: ~24 seconds (2 blocks)

Scalability

  • Contract can handle thousands of subscribers
  • Query operations are extremely fast (local reads)
  • No throughput bottleneck for typical creator use cases

Security Considerations

Smart Contract Security

  1. Arithmetic Safety:

    • Used Rust's overflow protection
    • Saturating arithmetic for critical calculations
    • Explicit type conversions with checks

  2. Access Control:

    • Creator-only functions properly protected
    • No privilege escalation vectors
    • Clear separation of concerns

  3. Reentrancy Protection:

    • Simple transfer logic
    • State updates before external calls
    • Minimal external dependencies

  4. Testing:

    • Comprehensive unit test coverage
    • Edge case validation
    • Multiple test accounts

Frontend Security

  1. No Private Key Handling:

    • All signing done in wallet
    • Frontend never sees private keys
    • User approves every transaction

  2. Input Validation:

    • Contract address verification
    • Amount validation
    • Error boundary handling

  3. RPC Security:

    • Uses official RPC endpoints
    • HTTPS/WSS only
    • No sensitive data logged

Deployment Strategy

Multi-Network Approach

We support both testnet and mainnet:

Shibuya (Testnet):

  • Free tokens from faucet
  • Safe testing environment
  • Same features as mainnet
  • Perfect for development

Astar (Mainnet):

  • Production deployments
  • Real value transactions
  • Verified contract code
  • Professional support

Deployment Process

  1. Build Contract:

    cargo contract build --release

  2. Deploy via UI:

    • Upload contract to Contracts UI
    • Set initial parameters
    • Pay deployment fee
    • Save contract address

  3. Configure Frontend:

    • Update contract address
    • Copy metadata file
    • Build and deploy

  4. Verify:

    • Test all functions
    • Verify on block explorer
    • Monitor for issues

Lessons Learned

What Went Well

  1. ink! Framework: Excellent developer experience
  2. Polkadot.js: Comprehensive and well-documented
  3. Astar Network: Reliable and fast
  4. Testing: Caught bugs early
  5. Modular Design: Easy to extend and modify

What Could Be Improved

  1. Frontend UI: Currently simplified; needs status displays and creator dashboard
  2. Frontend Testing: Need automated E2E tests
  3. Error Messages: Could be more user-friendly
  4. Documentation: Screenshots and videos help greatly
  5. Mobile UX: Could optimize for mobile wallets
  6. Monitoring: Need better analytics and alerts

Future Enhancements

  1. Enhanced Frontend UI: Real-time status displays, countdown timers, creator dashboard with withdrawal
  2. Multi-Tier Subscriptions: Different access levels
  3. NFT Integration: Subscription as transferable NFT
  4. Referral System: Reward user referrals
  5. Analytics Dashboard: Detailed metrics for creators
  6. Cross-Chain: Bridge to other networks
  7. Token Payments: Accept custom tokens
  8. Batch Operations: Manage multiple subscriptions
  9. Auto-Renewal: Optional recurring payments

Business Model

For Creators

Benefits:

  • Keep 100% of subscription revenue (minus minimal gas)
  • Instant access to funds (withdraw anytime)
  • No middleman or approval needed
  • Global audience reach
  • Transparent subscriber data

Costs:

  • Contract deployment: ~5-10 ASTR (one-time)
  • Gas per subscription: ~$0.0001
  • Gas per withdrawal: ~$0.0001

Break-even: Compared to 20% platform fee:

  • Break even at just 25 subscriptions at $10/month
  • Everything after that is pure savings

For Subscribers

Benefits:

  • Direct support to creators
  • Transparent pricing
  • Instant access
  • No hidden fees
  • Portable subscription (can be made NFT)

Costs:

  • Subscription price (set by creator)
  • Gas fee: ~$0.0001 per transaction

Impact and Use Cases

Ideal Use Cases

  1. Content Creators: YouTubers, podcasters, writers
  2. Artists: Musicians, digital artists, performers
  3. Educators: Course creators, tutors, coaches
  4. Developers: Open source maintainers, tool builders
  5. Communities: Discord servers, private forums, clubs

Real-World Example

Traditional Platform:

  • Creator: 100 subscribers × $10/month = $1,000/month
  • Platform fee (20%): -$200/month
  • Payment processing (3%): -$30/month
  • Net to creator: $770/month

CreatorDirect:

  • Creator: 100 subscribers × $10/month = $1,000/month
  • Gas costs: ~$0.01/month
  • Net to creator: $999.99/month

Savings: $230/month or $2,760/year!

Conclusion

CreatorDirect demonstrates that blockchain technology can solve real problems in the creator economy. By eliminating intermediaries and leveraging smart contracts, we can return value directly to creators while providing a better experience for subscribers.

The combination of ink! smart contracts on Astar with a React frontend powered by Polkadot.js provides a robust, scalable, and user-friendly solution.

Key Takeaways

  1. Blockchain enables new business models that were impossible before
  2. ink! makes smart contract development accessible to Rust developers
  3. Astar provides a production-ready platform for WASM contracts
  4. User experience matters even in Web3 applications
  5. Comprehensive testing is essential for contract security
  6. Documentation and education are as important as code

Try It Yourself

The entire project is open source:

  • GitHub: DevalPrime/creator-direct
  • Live Demo: Use the frontend to subscribe to the demo contract
  • Documentation: See README, ARCHITECTURE.md, and DEPLOYMENT.md

Get Involved

We welcome contributions:

  • Report bugs or suggest features via GitHub Issues
  • Submit pull requests with improvements
  • Share your deployment stories
  • Help improve documentation
  • Build on top of the contract

Resources

Final Thoughts

Building CreatorDirect has been an exciting journey into the intersection of creator economy and blockchain technology. The project proves that Web3 can offer practical solutions to real problems, not just speculation.

As blockchain technology matures and user experience improves, we believe decentralized creator platforms will become mainstream. CreatorDirect is a step in that direction.

Thank you for reading! If you have questions or want to discuss the project, feel free to reach out or open an issue on GitHub.

Built with ❤️ for creators everywhere

Powered by Astar Network and ink! smart contracts

Built With

Share this project:

Updates