Telegram action marketplace

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 settlement contract. Marketplace settlement contract (applies only after execution is enabled): the $1 platform fee per 100 successful actions is included in the lot price. Buyers pay nothing extra on top. Platform revenue will be $1 per 100 successful actions. Under that contract, only successful actions are billed; failed actions are not charged.

Per-lot math. The math of the contract, for any lot price P set by the owner: each successful action bills exactly P. All-in means the platform's $1 per 100 successful actions 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. The platform's $1 per 100 successful actions is inside P, so a lower price cannot contain the fee. Above the floor the price remains entirely the owner's decision. At the floor price ($0.01) the seller's share is exactly $0: the entire P is the platform's $1-per-100 fee. The floor is a technical minimum, not a price that makes sense for earning. A listing at the floor earns its owner nothing. The catalog itself shows what owners actually charge.

Verified success. Verified success for that future settlement 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.

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. Buying them is impossible in this phase too — no payment path exists until deposits open (see Where the money comes from above).

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.

Live now (the mechanism, not a completable purchase). Reservation checkout lets a signed-in buyer choose a real listing and receive a server quote. Completing a reservation requires two things this page publishes as absent — a fundable balance and at least one listed lot. Both turn on with published switches.

Where the money comes from: nowhere yet. A new account's USDT balance starts at $0 and there is no way to add funds in this phase. Deposits are not active, so a reservation checkout cannot complete until a balance can be funded. The switch will be announced on this page, as every switch is.

Status. Execution, settlement, and seller payouts — including any future seller payout hold — are not active in this step. Sign in and open Marketplace to see the reservation mechanism live. Completing a reservation also requires a fundable balance and at least one listed lot, both published as absent above.

Money circuit (reservation phase). The only money movements right now are the buyer's reservation, the self-service cancel, and the scheduled automatic release. Funds are held on reserve and fully released back on cancel or at the hold deadline (see Order rules below).

Deposits and withdrawals. Withdrawals are not implemented in this phase; deposits are off (see Where the money comes from above). No minimum deposit is set. Withdrawal methods and withdrawal fees are not approved yet — they will be published before payouts are enabled. The circuit opens in phases: deposits first, then execution and settlement, then payouts.

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 not chosen yet; the network will be named on this page before deposits open.

Switches never touch holds. A phase switch never touches existing holds. Nothing is charged while execution is off. A held reservation has no execution run behind it. Every hold is auto-released on schedule (see Order rules below). A switch cannot turn your reservation into a billed order. Only an explicit start you make after the switch can begin execution.

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.

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.

Liability. This risk belongs to the account owner. Liability in case of an account ban is not defined yet; it will be published before execution is enabled.

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 today — the "not defined yet" liability line means exactly that. Listing requires signing out other clients' sessions and giving up personal use of the account. The ban risk belongs to the account owner until a liability policy is published before execution is enabled.

Order rules (reservation phase). Reserving freezes the all-in amount from the price snapshot frozen at quote time; nothing is charged while execution is off. Cancel before start: the buyer cancels a held order self-service and the full reservation is released back to their balance. Success (future settlement contract): Telegram accepted the action without 403 or spamblock; failed actions are not charged; leads, replies, and sales are never guaranteed.

Disputes and partial fulfillment. Partial fulfillment, disputes, and contested success: their rules will be published before execution is enabled. In this phase no held order can be billed or forfeited.

Automatic release. While execution is off, a held 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. Hold rules for long-running jobs after execution is enabled will be published before execution is enabled. Until then no dispute can exist: nothing is billed and nothing is forfeited in this phase.

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 before execution is enabled. 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, active once execution is enabled.

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.

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 — this is the reservation phase, 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.

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.

Own a Telegram account? The same sign-up on the right is how you become a seller. Listing is self-service and free of plan quotas. Legacy subscription plan quotas do not apply to listings; the only limit is one active listing per account.

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 five fields 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. There are no payouts yet; listing now is claiming a spot, not earning today. 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 (reservation phase). In this phase a reservation passes no texts, audiences, or content for DMs, comments, posts, or mailings. A held order fixes only the listing and quantity at the reserved price.

Content ownership. Who prepares texts and audiences for DMs, comments, posts, and mailings will be published before execution is enabled. So will the exact input contract for each action type (what a buyer must provide).

No creatives stored. In this phase the platform stores no creatives (no ad texts or images), and nobody — platform or seller — sees any. A reservation accepts no content, so there is nothing to store or expose. The per-action input contract, including storage and visibility rules, will be published before execution is enabled.