Frontend Codes

Build interfaces for Curyo and earn cREP frontend fees from votes made through your frontend.

Overview

Frontend operators who build frontends, mobile apps, or integrations receive 3% of the remaining 95% from settled two-sided rounds on votes made through their interface.

How to Register

1. Stake 1,000 cREP to the FrontendRegistry contract.
2. Await governance approval before you can start earning frontend fees.
3. Integrate: Include your registered address in the vote payload sent through CuryoReputation.transferAndCall().
4. Claim: First call RoundRewardDistributor.claimFrontendFee(contentId, roundId, frontend) on each settled round, then withdraw your accumulated cREP from FrontendRegistry.claimFees(). If governance slashes your frontend, you must restore the full 1,000 cREP bond before fee claims can accrue to you again.

Integration

Include your frontend address in the payload you send through the single-transaction vote flow:

CuryoReputation.transferAndCall(
    votingEngineAddress,
    stakeAmount,
    abi.encode(
        contentId,
        commitHash,
        ciphertext,
        frontendAddress // Your registered frontend address
    )
)

Or set the NEXT_PUBLIC_FRONTEND_CODE environment variable to your address and the SDK will include it automatically.

Running a Resolution Service

Every frontend operator should also run a resolution service — a background service that keeps the protocol moving. It performs three critical tasks:

1. Revealing votes: After each 20-minute epoch ends, the service decrypts tlock ciphertexts using the drand randomness beacon and calls revealVoteByCommitKey(contentId, roundId, commitKey, isUp, salt) for each unrevealed commit. Votes stay hidden until this step runs.
2. Settling rounds: Once at least 3 votes are revealed and all past-epoch votes have been revealed (or the 60-minute reveal grace period has expired), the service calls settleRound(contentId, roundId) to finalize the round, update the content rating, and open rewards for claiming.
3. Finalizing and cleanup: If commit quorum was reached but reveal quorum never materializes by the final grace deadline, the service can call finalizeRevealFailedRound(contentId, roundId). After terminal states, it should also batch processUnrevealedVotes(contentId, roundId, startIndex, count) so unrevealed stakes are swept or refunded.

Without resolution services, votes would never be revealed and rounds would never resolve. Running one alongside your frontend ensures a smooth experience for your users and contributes to the health of the network. Since these actions are permissionless, anyone can run a resolution service. Reveal still relies on off-chain drand decryption rather than an on-chain proof that the stored ciphertext was honestly decryptable, so the keeper is a trust-minimized convenience layer rather than a cryptographic gatekeeper. The more independent services running, the more resilient the network becomes.

Running an Indexer / Back-End

For the best user experience, frontend operators should run their own indexer and/or back-end service. Reading blockchain data directly from an RPC node for every page load is slow and expensive. An indexer listens to contract events and stores the data in a database so your frontend can query it instantly.

• Faster load times: Pre-indexed data means your UI doesn't wait for RPC calls to return historical state.
• Lower RPC costs: Batch-synced data reduces the number of calls to your RPC provider.
• Richer queries: An indexed database lets you filter, sort, and aggregate data in ways that direct blockchain reads alone cannot support efficiently.

The reference implementation uses Ponder as its indexer. You are free to use any indexing stack (Ponder, The Graph, custom solutions) as long as your frontend can serve data quickly and reliably.

Content Moderation

Frontend operators are allowed and encouraged to implement client-side content moderation to comply with local regulations and their own platform policies. Because Curyo is a decentralized protocol, there is no protocol-level censorship — content submitted to the blockchain is permanent. However, each frontend is free to decide what it displays to its users.

The reference implementation includes a keyword-based blocklist that:

• Blocks submissions containing prohibited terms in URLs, titles, descriptions, platform names, and domains.
• Filters the feed so that content matching the blocklist is hidden from users automatically.
• Notifies users with clear warning messages when their input is rejected.

Frontend operators can customize and extend their moderation approach in several ways:

• Keyword filtering — Expand or adjust the built-in blocklist of prohibited terms for URLs and text.
• Domain blocklists — Maintain a list of domains that should never be displayed or submitted.
• Third-party moderation APIs — Integrate services like content safety classifiers for more sophisticated filtering.
• Manual review workflows — Implement flagging and human review for edge cases.

Each frontend operator is responsible for the content they serve to their audience. The moderation logic lives entirely in the frontend codebase and has no effect on the underlying protocol or other frontends.

Governance Oversight

Frontend operators are subject to governance control:

• Approval required before earning frontend fees.
• Slashing — Governance can slash staked cREP for abuse and confiscate already accrued frontend fees.
• Revocation — Governance can revoke approval at any time.
• Rebonding required — After a partial slash, operators must top back up to the full 1,000 cREP stake before governance can approve them again.