seller rules

01authority to connect a channel

sellers confirm their authority to use the endpoint and key, resell access and authorise 2api to execute requests. stolen keys, unauthorised accounts, concealed model substitution and false capability claims are prohibited. an origin description is optional, but any published claims must be accurate.

02application and testing authorisation

an application includes a channel name, an endpoint ending in /v1, a key, selected models and a private contact. fetching /models imports identifiers only and does not verify a model.

before the first call, sellers separately authorise model listing, technical checks and repeat verification approximately every 48 hours. test calls consume tokens and may debit supplier balance. request limits and estimated usage are shown before submission. actual cost depends on rates, output length, reasoning and provider instructions. sales pause during rechecks; successful rechecks restore previously published offers. consent does not authorise unlimited spending.

checks use service-authored synthetic tasks and automatic analysis of the protocol, declared capabilities and usage data. reference comparison and AI judging are disabled. technical approval does not establish model identity or the absence of hidden instructions. credentials, contacts and buyer requests are excluded from public reports.

03model approval

each model is checked separately. the initial target is 15–20 minutes, not a guaranteed turnaround. queues, connection failures and additional review may take longer. elapsed time never grants approval.

only approved models on the reviewed configuration may be published. an uncertain model remains under additional review; other models are assessed independently unless the issue affects the whole channel. material endpoint, key or model changes require renewed approval.

04rates and publication

after approval, sellers set base rates for all supported usage categories and explicitly publish the offer. 2api shows customers the final price and sellers their own rates and earnings. prices are versioned and do not alter requests already in progress. cache accounting and partial-request billing must be settled before sales open.

05earnings and withdrawals

the workspace separates pending earnings, available funds and amounts reserved for withdrawals. only available funds can be withdrawn. the minimum request is 20 dollars, settled in USDT on disclosed conversion terms; USDT is not represented as unconditionally equal to USD.

planned networks are TON, TRON (TRC-20) and BNB Smart Chain (BEP-20). sellers select a network, enter an address and amount, and confirm the details. fees, conversion and the net amount must be shown before a real request. who bears network fees will be specified in the final revision.

the processing target is within 24 hours; blockchain confirmation time may differ. submission reserves the amount, and a transaction identifier is recorded after an actual transfer. a rejected unsent request releases its reservation. disputed funds may be restricted only with stated grounds and review, not indefinitely without explanation.

06customer data and suspension

sellers are responsible for lawful handling of data received by their channel and for their suppliers’ terms. customer requests must not be repurposed without authorisation, secretly resold or published. violations, substitution or security threats may suspend sales; sellers receive a reason and a way to request review through the published contact.