Telegram action marketplace
For two roles: Action buyers and Account owners.
Pricing
Pricing. The account owner sets the lot price. A lot is one account offer for rent. Two terms used below: settlement means how finished deals turn into payments; execution means the phase when paid actions actually run.
The commission contract. Marketplace commission contract (applies to every executed marketplace order): the platform takes a 10% commission on each successful action; the seller receives the remaining 90%. The commission is taken from the lot price at settlement — buyers pay nothing extra on top. Under that contract, only successful actions are billed; failed actions are not charged. Settlement is instant: no payout hold and no insurance withhold. The platform's only revenue is the 10% commission on each successful action.
Per-lot math. The math of the contract, for any lot price P set by the owner: each successful action bills exactly P — 90% of P credits the seller's balance instantly, 10% is the platform's commission. All-in means the commission is inside P, not on top. Each failed action bills 0. A reservation holds quantity × P — a hold is money set aside for an order. The unused hold is released on cancel or stop.
Why no reference prices. Reference prices are not published — by design. Pricing is entirely the owner's decision. An empty catalog offers no market data to cite. The catalog itself shows the going price once it holds several lots (live USDT prices, easy to compare side by side). While it holds a single lot there is nothing to compare against. The platform will not invent numbers.
Lot price floor: price_per_result must be at least $0.01 per action. Above the floor the price remains entirely the owner's decision; the platform's 10% commission is a share of P at any price. At the floor price ($0.01) the seller's share is 90% of P and the platform's commission is 10% of P. The floor is a technical minimum, not a price that makes sense for earning. A listing at the floor earns its owner almost nothing. The catalog itself shows what owners actually charge.
Verification & billing
Verified success. Verified success for that commission contract means Telegram accepted the action without 403 or spamblock. Here 403 is a blocking error code, and spamblock is Telegram blocking an account. Leads, replies, and sales are not guaranteed. Leads here means new contacts.
What a billed action guarantees. A billed result means Telegram accepted the action on the acting account's own log — nothing more. For DM, broadcast, comment, and post actions: guaranteed — the send was accepted without 403 or spamblock; not guaranteed — inbox placement, spam-folder avoidance, reads, replies, or sales. For invites: guaranteed — the invite was accepted by Telegram; not guaranteed — that the user joins (checking joining is possible only with access to the buyer's channel, by agreement, outside the base guarantee). Every billed or failed action keeps its raw Telegram outcome in the order's event stream.
How success is verified. Many results you can check directly in your own Telegram. New members appear in your group or channel, and public comments appear under the target post. You do not need to ask the platform. Every job also carries a machine-readable trail (a record software can read; see Interface below). No outside auditor is provided.
Paid actions: DM, comments, invites, reactions, posts, and chat broadcasts. Profile generation: $0.02; avatar/image generation: $0.05.
Billing rule. Billing counts one result kind per action type. The live code counts exactly six kinds: delivered, contact, invite, reaction, post, and broadcast. Each of the six paid action types bills under its kind. Every kind bills under the same success rule: Telegram accepted the action without 403 or spamblock; failed actions are not charged.
DIY tools are not lots. Profile generation and avatar/image generation are DIY platform services (DIY = do it yourself) priced per piece. They are not marketplace lots. They cannot be reserved, listed, or bought on the marketplace, and they produce no result kind that gets counted. They apply to your own accounts through the platform tools. They are not purchasable on the marketplace in any phase (see Where the money comes from above for how balances are funded).
Free tools & scope
Free for account owners (the selling side): warmup, BYOK, GLM 5.3 Flash low @ RelayModels (1M tokens/day/user), and MTProto pool proxies. Warmup means gradual account preparation. BYOK means bring your own keys. These are tools to prepare your own accounts for listing and to run your own actions — not part of the buyer offer. MTProto pool proxies are not available for rented actions.
Scope. Story views and mass-looking are not marketplace actions: they are not offered on this marketplace at any price or under any terms.
Status
Live now. Reservation checkout lets a signed-in buyer choose a real listing and receive a server quote, and a started order runs real actions on the listed accounts. Both a fundable balance and at least one listed lot are required.
Where the money comes from: USDT (TRC20) deposits to the platform's published address are wired into the Wallet block below — a deposit request gets a unique amount, you transfer that exact amount on-chain, and the credit is verified on TronGrid before it reaches your balance.
Status. Execution is active for marketplace orders: a started order runs real actions on the listed accounts and bills only successes; settlement is instant per successful action; seller payouts run manually — a withdrawal request is paid by the operator. Sign in and open Marketplace to reserve an order or start one. Completing a reservation also requires a fundable balance and at least one listed lot.
Money circuit (live). The money movements are deposits, the buyer's reservation, the self-service cancel, the scheduled automatic release, instant per-result settlement on executed orders, and manual seller withdrawals. Funds are held on reserve and fully released back on cancel or at the hold deadline (see Order rules below).
Deposits and withdrawals. Deposits: USDT on the TRC20 network, sent to the platform address published in the signed-in Wallet block; the credited amount is matched to your deposit request by the unique amount, verified on TronGrid, and appears in your balance as soon as it is confirmed. Withdrawal requests are accepted in the Wallet block and paid manually by the operator. Deposits are accepted: a deposit request gets a unique amount and is credited after the on-chain TronGrid verification. Withdrawal is a manual review step, not an instant transfer. No minimum deposit is set. Withdrawal methods and withdrawal fees are not approved yet — they will be published before payouts are enabled. The money movements are deposits, the buyer's reservation, the self-service cancel, the scheduled automatic release of never-started orders, instant per-result settlement on executed orders, and manual seller withdrawals.
Switches are published. Each switch is published on this page before it turns on — no switch flips silently. The signal of a switch is this page itself: the Status block above changes when a phase opens — no dates, no off-page announcements. USDT is the only money unit used; the deposit network is TRC20 (USDT on TRON).
Switches never touch holds. A held reservation has no execution run behind it: nothing is charged until you explicitly start the order. Every hold is auto-released on schedule (see Order rules below). A switch cannot turn your reservation into a billed order — only your explicit start can begin execution.
Risks and limits
Risks and limits (disclosure). Telegram may restrict or ban accounts: 403 responses and spamblock are possible. An action that gets either is counted as failed — failed actions are not charged.
Daily limits and queue. Actions run under the daily limit of each account, shared by own and rented campaigns on a first-come, first-served basis. The exact daily numbers (initial cap, post-warmup cap, warmup days) are published on the login page and always reflect the live settings. Listing becomes possible only once the account passes the gate's minimum age. With the published numbers, that minimum age already sits past the warmup window, so every catalog lot runs at the post-warmup daily cap. The initial, lower tier applies only to accounts younger than the listing gate. First-come, first-served means whoever asks first is served first.
Rented actions and proxies. Rented actions run only through the account's frozen proxy; the free MTProto pool is not available for rented actions. The account's proxy is frozen: its connection address is fixed and never replaced. The proxy is part of the seller's asset; the platform does not sell proxies. If a proxy dies mid-order, execution on that account stops and its actions are not billed (fail — nobody pays).
Listing risk. Listing signs out other clients on the Telegram account and requires the owner to give up personal use of the account. Listing proves control of the session, not its origin: signing out other clients is only possible while holding the session, which is what the gate verifies, together with activity, age and trust state.
Provenance and reclaim. How the session was originally obtained is not verifiable by the platform, and no claim about a session's provenance is made. If a session's true owner reclaims the account mid-order, rented actions fail, and failed actions are not charged.
Session lifecycle, storage, and incidents. Listing signs out all foreign Telegram authorizations of the account in a single connection; during the listing period the account performs marketplace actions only. Removing the lot returns control immediately: the platform deletes its copy of the session credentials and reports the account status as-is (including spamblock) — the platform neither repairs nor retains accounts. Session credentials are encrypted at rest and accessible only to the execution engine; no copies are kept. Incident rule: on suspected compromise the platform immediately signs out every session on the affected accounts (the same one-connection reset) — accounts stay with their owners, who log in by phone number.
Exit protocol. The platform never owns an account — it holds the session only for the listing period. When the seller stops a lot (or the platform shuts down), every session string returns to its owner as-is, the platform deletes its copies and signs out its own sessions; buyer balances remain claimable and are returned by request in USDT.
Liability. This risk belongs to the account owner. Liability in case of an account ban is not defined yet; until a liability policy is published, the ban risk belongs to the account owner.
Legal status (pre-launch). No legal entity, no Terms of Service, and no Privacy/Offer contract are published yet. This is a pre-launch storefront where no transaction can occur in this phase. These will be published on this page before deposits open — not after the fact.
Position on Telegram ToS risk. Renting out accounts and running bulk actions may violate Telegram's Terms of Service; 403 responses and spamblock are real, known risks. No insurance or compensation exists in this system — the insurance-fund mechanism was removed: the seller receives their 90% share immediately. Listing requires signing out other clients' sessions and giving up personal use of the account.
Ban-risk matrix (who owns which cause). The platform owns the pace and the engine: free warmup for every account, published pace gates (3 actions/day for the first 7 days of an account's life, then 6/day), and the frozen-proxy execution engine. The buyer owns the content it supplies: texts and targets must comply with Telegram's rules. The seller owns the account's intrinsic quality: a ban before the lot's first billed action is the seller's zone; after that, cases are resolved through the Telegram log (see Disputes). Ban statistics are published as machine counters in the honesty record.
Liability default. Until a liability policy is published, the ban risk is split by cause — see the ban-risk matrix above.
Order rules
Order rules (live execution). Reserving freezes the all-in amount from the price snapshot frozen at quote time; nothing is charged until you start. Starting an order runs real actions on the listed accounts and bills only successes. Cancel or stop releases the unused hold back to the buyer's balance. Success: Telegram accepted the action without 403 or spamblock; failed actions are not charged; leads, replies, and sales are never guaranteed. Settlement is instant per successful action: on every billed result 90% of the lot price credits the seller's balance immediately, the platform keeps its 10% commission — no payout hold and no insurance withhold.
Disputes. The first arbiter is the automatic Telegram log: every action's raw outcome — success or the Telegram error (403, spamblock) — is recorded in the order's event stream, visible to the buyer via GET /api/v1/shared/jobs/{id}?events=N. A contested verification is resolved manually by the platform admin, whose decision is the last instance. Default: an unverifiable or failed action is a fail — nobody pays.
Automatic release. A reservation hold is not a charge. A held, never-started order is released in full to your balance 72 hours after reservation. Cancelling manually is not required and there is nothing to remember. The system releases it automatically on a schedule after the deadline. No notifications are sent. The refund needs no guesswork: the order status shows it. GET /api/v1/shared/jobs/{id} returns hold_status=refunded with hold_released_at — the released amount is already on your balance when you return.
Queue and budget. Paying does not buy queue priority. Lots are served strictly first-come, first-served. A job's real speed comes from the lot's daily budget — visible at quote time as account_daily_budget_remaining_today. Checkout does not reserve the account's daily budget. The quote figure is a snapshot at quote time. The budget is checked when the action actually runs. Between quote and execution the remaining budget can drop, and an action with no budget left at run time is not executed.
Held reservation orders. For reservation orders the case cannot arise. A marketplace checkout order sits held with no execution run behind it. Its hold is refunded in full by the same scheduled automatic release (see Automatic release above). There is no running job for the release to interrupt and no notifications are sent.
If you do not come back. There is nothing to lose by not coming back. If nobody opens the system for a day or a month, the held amount stays in the ledger untouched. It is excluded from your available balance, never forfeited, never burned, and its refund never expires. The scheduled automatic release after the deadline converts the hold into a refund whether or not anyone is looking.
Check any time. The order's state and telemetry are checkable at any moment via GET /api/v1/shared/jobs/{id}. Your balance is checkable via /api/auth/me or the SPA. No notifications are sent, and none are needed. Checking in is optional and never costs you the money.
No interest, verifiable release. A held order earns no interest and carries no yield: its amount is fixed at the reserved total for the whole hold. The scheduled release leaves a verifiable trace, not a silent event. GET /api/v1/shared/jobs/{id} shows the hold's status: pending until the scheduled release, refunded after, with the release timestamp. The refund appears in your balance. Notifications are still not sent, because none are needed to verify the release.
Future hold rules. A started order bills per delivered action and can be stopped at any time; stopping releases the unused hold immediately (POST /api/v1/shared/jobs/{id}/stop). Long-running hold rules beyond this are not established yet.
Public interface
Interface and operations (verified facts). The public API is live. POST /api/v1/shared/fleet/search reads the catalog. POST /api/v1/shared/checkout reserves a lot. GET /api/v1/shared/jobs/{id} returns order status. POST /api/v1/shared/jobs/{id}/stop cancels your order via the API.
API keys and MCP. API keys (dtg_live_*) with scopes are managed via /api/v1/keys. Scopes are permission flags. MCP JSON-RPC (initialize, tools/list, tools/call) is served at POST /api/v1/mcp.
Listing gate. Listing moderation is an automatic code gate. The gate checks: active account, trust at or above the floor, minimum account age, and other clients' sessions signed out at listing. There is no manual moderator.
Support and deadlines. Support, SLA and execution deadlines are not established yet; they will be published here. SLA means promised speed and response times.
Public catalog and audit trail. Public read-only catalog: GET /api/v1/shared/catalog — real lots and USDT prices, no sign-in required. Every job carries its own machine-readable result trail. GET /api/v1/shared/jobs/{id} returns the delivered-results breakdown and the tail of the per-result event stream. Results are auditable through the API on every executed order.
Spec and honesty record. Machine-readable API spec: GET /_openapi.json (OpenAPI, covers all /api/v1/shared endpoints and scopes), browsable Swagger UI at /_docs — both public, no sign-in. Public honesty record: GET /api/v1/shared/honesty — the copy-contract version, SHA-256 of both surfaces, and the published switches and absences, machine-readable, no sign-in.
Trail format (field names from the live code; values appear with real jobs). GET /api/v1/shared/jobs/{id} returns: id, family, state, listing_ids, budget_cap, spent, action_run_id, created_at. It also returns leads, recent_events, hold_status, hold_released_at.
Events window. The events tail defaults to the last 20; pass ?events=N (up to 10000) for a longer window — the full per-result stream is auditable from the API. leads is a per-kind count of billed results. recent_events is the tail of the per-result event stream. Each event carries kind, amount, job_spent and billing flag.
Result kinds and amounts. Result kinds counted: delivered, contact, invite, reaction, post, broadcast. amount is the all-in lot price actually billed for that result; budget_cap minus spent is what is still held. hold_status is pending until the scheduled release and refunded after; hold_released_at is the release timestamp.
Stop response. POST /api/v1/shared/jobs/{id}/stop returns: job_id, state, spent, released — released is the amount returned to your available balance.
Published listing-gate numbers: minimum account age 7 days; trust floor 50 of 100. Published daily action budget per account (one first-come, first-served budget shared by the owner's own and rented campaigns): 3 actions/day for the first 7 days of the account's life, then 6 actions/day.
Trust score & track record
What trust means. trust_score on a lot card is the platform's internal account-health score (how safe and normal the account looks) on a 0–100 scale. The platform computes it from visible account facts. They include registration age, profile-photo freshness, and facts about owned channels (channel age, last-post views). Warmup history in hours, Telegram Premium now or in the past, gifts count, and an attached email count too. Current or past spamblock events are part of the score. The exact weights are internal and not published.
Trust floor and limits. The published listing-gate floor (trust 50 of 100) is the platform's minimum acceptance bar: lots below it cannot appear in the catalog at all. Trust is not a success rate, review score, or seller reputation — it says nothing about past deals.
Lot card fields. profile photo = the Telegram account has a profile photo. Telegram Premium = the account holds an active Telegram Premium subscription. country = the account's country on record; it can be empty. These fields describe the rented account itself — not the account owner and not a channel. They are shown for information only: the platform does not adjust lot prices by them — pricing is entirely the owner's decision. The catalog can be filtered by geo (the listing's geo label), by min trust, and by max price. The geo filter matches the listing's geo label, which the owner sets; the card's country is the account's country on record. The platform does not enforce a link between the two.
Track record (honest zero). No commercial transactions have happened yet — the exchange is live and empty, and there are no testimonials to quote. Instead of invented social proof, the facts you can check are public. The read-only catalog carries real USDT prices. The fixed listing-gate and daily-budget numbers are published on this page. The honesty record (GET /api/v1/shared/honesty) publishes the machine counters — orders, billed results, GMV, bans — check them as the exchange grows.
Published absences only. Storefront copy states payment, support, and insurance only as published absences or published switches. Check each statement against the public endpoints in the Interface block above. The honesty record (GET /api/v1/shared/honesty) publishes this page's contract version and surface hashes. The check is machine-readable, not taken on trust.
Seller reputation. Seller reputation is not invented in advance. Every delivered result is already recorded in an append-only per-job billing trail (append-only means records are only added, never edited). The reputation layer will be computed from that trail — nothing else, nothing made up. It turns on with the first real deals.
Real cases. Commercial cases will appear here automatically, collected from the public per-job trail — no selected case studies. The first real job will be the first case.
Live catalog
Sell your accounts
Own a Telegram account? The same sign-up on the right is how you become a seller. Listing is self-service; the only limit is one active listing per account. Seller payouts are manual: a withdrawal request is queued and paid by the operator. Listing now means the account can earn from the first billed action.
How to list. Sign in and create a listing via POST /api/v1/shared/listings (auth: your JWT login token). Fields: account_id, price_per_result, labels, note, release_personal_use. The automatic gate numbers (account age, trust floor) are published on the login page; there is no manual moderator. A minimal listing form is built into the Marketplace panel after sign-in. It has the same fields (including the required gender and language labels) and the same automatic gate, in the browser. The API and MCP JSON-RPC remain the working paths.
Listing is free. Why list now: listing is free, and the catalog is public — buyers see your lot from the first day the marketplace opens for real orders. The automatic gate numbers are published on the login page. Once a lot delivers results, the seller's 90% share of each successful action is credited to their balance instantly — no payout hold. The form posts exactly the listing fields above — nothing more.
Pause and resume. You can pause or resume your listing at any time from the listing panel. A paused lot disappears from the catalog immediately and the account returns to your personal use. Other clients signed out at listing time are not signed back in.
Inputs & content
Inputs (what an order needs). A reservation fixes only the listing and quantity at the reserved price. Starting an order passes your job configuration (for example target chats or usernames for the action family) to the execution engine. The exact input schema per action family is not documented yet and will be published here.
Content ownership. For comment actions the platform generates comment texts with the account's configured tone — buyers supply targets, not creatives. For the other action families the content contract will be published here as each family opens.
No creatives stored. The platform keeps no creatives library. An order stores only the job configuration it needs to run (targets and family parameters) next to the order record; comment texts are generated per action, not stored as a library. The per-action content contract, including storage and visibility rules, will be published here.