Documentation menu
KOLRelay product documentation.
KOLRelay connects project demand, individual creators, and community crews in one accountable work loop. Telegram is the first product surface; Mercur and Medusa provide the operations foundation for a potential complementary web workspace.
This guide describes the intended product and implemented components. Telegram, payments, cross-platform verification and any web workspace require configuration and end-to-end validation before being presented as live.
Creator marketing is growing. Coordination still matters.
Projects need credible distribution, creators need transparent opportunities, and communities need a practical way to coordinate participation. KOLRelay is designed as a Telegram-first marketplace for that work: a shared workflow for briefs, matching, delivery and review.
These figures describe the broader U.S. creator advertising market, not Web3, Telegram or KOLRelay revenue. The 2026 figure is a projection. No KOLRelay market share is claimed.
Where work breaks down
Briefs, participant selection and approvals often end up across disconnected messages. KOLRelay’s intended workflow keeps the task, terms and next step together.
Creators and projects need attributable evidence and agreed acceptance criteria. IAB identifies fragmented metrics and verification as industry challenges; KOLRelay is designed to capture delivery evidence, not guarantee campaign ROI. IAB measurement landscape ↗
Paid promotion needs clear terms and appropriate sponsorship disclosure. The product’s intended checks support that process; participants remain responsible for applicable requirements. FTC guidance ↗
Web3 quest products such as Galxe Quest organize rewarded participation. KOLRelay focuses on coordinating disclosed creator and community marketing work through Telegram, with an operations foundation for orders, fees and settlement. This is a product direction, not a claim that every integration is live.
Product boundary
A Telegram user is a participant. The same participant can publish a task today and complete one tomorrow; buyer and seller are transaction roles, not permanent account types.
The intended Telegram flow lets participants join, draft, browse, apply, submit and review without requiring a separate marketplace website. A web workspace may complement that flow without replacing it.
Complementary web workspace
The codebase includes an early campaign drafting and management workspace backed by Mercur and Medusa. It is not yet offered as a live, unified Telegram and web experience: shared identity, authorization, campaign ownership and end-to-end settlement must first be verified. Payment and social adapters remain gated until their own release checks pass.
For projects
The publishing flow collects task language, category, title, scope, budget, deadline, and proof requirements. The first intended release covers Telegram channel KOL content and community promotion; the native payment rail remains gated pending launch checks.
- Create a scoped task with a deadline 1–90 days ahead.
- Review applicants and select a participant.
- Freeze the selected scope and exact fee order.
- Accept, request revision, or dispute submitted work.
- Recognize revenue and reputation only after trusted settlement.
Task language is selected by the publisher. Browsers can filter by language or show all; multilingual tasks appear alongside a selected language, while older unclassified tasks remain visible under All or Unspecified. This does not automatically translate or independently verify the task text.
For creators
Creators use the task hall, applications, My Work, proof submission, and transaction-bound ratings. Ownership binding connects a Telegram participant to the channel used for delivery.
A separate campaign verification workflow checks a bot-observed post, verified channel, publication window, canonical message ID and approved-content fingerprint. It is not yet connected to every Bot task submission; those submissions can require project review. Screenshots alone do not trigger automatic settlement.
Crew execution
Community crew coordination is planned and is not yet available in the Bot. The intended workflow would retain an individual participant, evidence, review state and payout decision for each slot.
- Batch assignment and member distribution are not available yet.
- Any future coordination fee must be separately disclosed.
- Individual evidence and settlement identities are design goals that require testing.
Verification lanes
Auto pass
The separate campaign verifier can pass when its implemented ownership, timing, observed-post and content checks agree. This is not a guarantee of genuine audiences.
Risk hold
Missing or ambiguous evidence requires review. Automated cluster detection and random sampling are not yet implemented.
Auto reject
The campaign verifier rejects certain identity or post-ID mismatches and holds reuse of an already verified post. Cross-account collusion and Bot-task-wide duplicate detection remain unfinished.
Bot task proof is not yet automatically verified end to end. Review capacity and operational procedures must be established before launch.
Payments and fees
The current default is a separate 15% platform fee calculated from the task budget. Fee payment, recognition, refunds and referral rewards have separate states; production payment and reconciliation still require end-to-end testing.
The 1,000 XTR task budget is not KOLRelay revenue. Telegram's own commission is a provider cost and is not described as platform income.
Reputation and referrals
Both sides can leave one 1–5 rating only after delivery and confirmed payment. A trusted refund invalidates the related ratings. First-touch referral attribution is immutable; self-referrals and invalid codes enter manual review.
A reward is 20% of the platform fee actually received—not 20% of gross task value—and exists only after a real settled transaction.
Quotas and restrictions
Publishing, applications, concurrent assignments, and crew slots are tiered. Standard requires at least 3 verified completions and a 4.5 rating; Trusted requires 20 completions and a 4.8 rating. Two open disputes or two overdue assignments restrict new publishing and applications while existing delivery and support remain available.
Platform status
| Platform | Orchestration | Primary proof | Settlement |
|---|---|---|---|
| Telegram | First release path | Bot events, ownership, Suggested Post state | Stars (XTR) · activation gated |
| X | In preparation | Planned: authorized API + permalink | Disabled until credentials and tests pass |
| In preparation | Planned: authorized API + permalink | Adapter-gated | |
| TikTok | In preparation | Planned: authorized API + permalink | Adapter-gated |
| YouTube | In preparation | Planned: authorized API + public video | Adapter-gated |
An adapter is marketed as live only after credentials, ownership binding, idempotent event ingestion, replay and reconciliation, adversarial proof tests, refund behavior, monitoring, and an operator runbook all pass.
Safety boundary
KOLRelay supports legitimate Web3 education, product walkthroughs, community work, translation, research, events, and disclosed creator marketing.
It does not support fabricated followers or engagement, fake TVL or user claims, hidden sponsorship, sybil or airdrop farming, wash trading, price or volume manipulation, return guarantees, custody of private keys, or anonymous off-book transfers.
If a platform or payment adapter cannot prove ownership, ingest trusted events, refund safely, and reconcile state, the Bot hides or rejects that path instead of creating unpayable work.