generated: '2026-08-27' method: derived source: openapi/mystars-faas-openapi.json + https://mystars.tg/docs + well-known/mystars-security.txt docs: https://mystars.tg/docs note: >- Cross-cutting standards assertions. Each entry is judged against the published contract or a document actually fetched from a MyStars host; where a standard is claimed nowhere and shows nowhere in the spec, conforms is false with the evidence that made it false. standards: - id: openapi-3.1 conforms: true evidence: >- openapi: 3.1.0 served at https://mystars.tg/openapi.json (200, application/json) and https://mystars.tg/openapi.yaml (200, application/yaml). 9 operations across 3 tags, plus a webhooks block. Every operation has an operationId, a summary, a description, tags, a 2xx and at least three 4xx responses; securitySchemes is defined and applied globally. - id: rfc9457 conforms: false evidence: >- Errors are application/json with a custom { error: { code, message, telegram_message? } } envelope, not application/problem+json. The codes are a stable enum, so the envelope is machine-branchable — it is simply not the RFC. - id: idempotency conforms: true evidence: >- Idempotency-Key is a REQUIRED header on POST /v1/orders (components/parameters/IdempotencyKey). Same key + identical body replays the original order (200 vs 201 on first create); same key + different body is 409. Documented in the overview's "Idempotency" section and implemented in both official SDKs. - id: ietf-ratelimit-headers conforms: true evidence: >- RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset — the IETF draft ratelimit-headers field names — plus Retry-After, documented in the overview's "Rate limits" section and named in the RateLimited response description in the spec. Not observed live: /v1 requires a key. - id: pagination conforms: true evidence: >- GET /v1/orders is keyset-paginated with an opaque cursor: limit (1..100, default 50) and cursor query parameters, next_cursor in the response, null on the last page, newest first. - id: rfc9116 conforms: true evidence: >- https://mystars.tg/.well-known/security.txt returns 200 with Contact, Expires (2027-06-10, unexpired), Preferred-Languages and Canonical. Saved verbatim to well-known/mystars-security.txt. It carries no Policy, Encryption, or Acknowledgments field. - id: oauth2 conforms: false evidence: >- The only securityScheme is ApiKeyAuth (apiKey, header, X-Api-Key). No OAuth flows in the spec, and /.well-known/oauth-authorization-server + /.well-known/oauth-protected-resource return 404 on both mystars.tg and api.mystars.tg. - id: oidc conforms: false evidence: /.well-known/openid-configuration returns 404 on both hosts. - id: json-api conforms: false evidence: Plain application/json resource shapes; no JSON:API media type, document structure or links object. - id: odata conforms: false evidence: No $metadata surface and no OData query options. - id: scim conforms: false evidence: No user/group provisioning surface; there is no identity resource in the contract. - id: webhook-signing-hmac conforms: true evidence: >- The orderStatus webhook carries X-Faas-Signature — hex HMAC-SHA256 of the exact raw request body under a per-tenant webhook secret, the same scheme Stripe and GitHub use. Documented with the multi-signature comma-separated rollover form for secret rotation. domain_standards: - id: ton-tep-74 name: TEP-74 (TON Jetton standard) conforms: true contract_location: components/schemas/PaymentInstruction.pay_to_address evidence: >- The contract declares its settlement mechanics in TON's own standard terms rather than a bespoke scheme: USDT is paid as a "TEP-74 USDT jetton transfer" whose destination is the treasury OWNER wallet (pay_to_address), with the memo carried as the forward-payload text comment and a small non-zero forward_ton_amount for forwarding gas — and the docs explicitly warn against sending to a derived jetton-wallet address. Named in the API overview at https://mystars.tg/docs and reflected in the pay_to_address schema description. Any wallet or integrator that already speaks TEP-74 needs no bespoke connector for USDT settlement. - id: ton-transfer-comment name: TON native transfer comment (memo) conforms: true contract_location: components/schemas/PaymentInstruction.memo evidence: >- Native GRAM payments carry the order id as the standard TON transfer comment; the same value doubles as the API's order_id, so one identifier spans the HTTP contract and the chain. - id: ton-deeplink name: ton:// transfer deeplink conforms: true contract_location: SDK payment builders (buildPaymentRequest / build_payment_request) evidence: >- Both official SDKs emit a ton://transfer/... deeplink from the PaymentInstruction block, openable in any TON wallet — documented on https://mystars.tg/docs/sdks. compliance: certifications: [] trust_center: none note: >- No SOC 2, ISO 27001, PCI DSS, HIPAA or FedRAMP claim anywhere on the site, and no trust center (probe-security-programs.py found none). This is consistent with the stated product posture rather than an oversight: MyStars markets itself as no-KYC and non-custodial, and the security story it does tell is architectural — the API key alone cannot move funds because every order is settled by its own on-chain payment, and the optional wallet SDK keeps the signing key in the caller's process. No Compliance pointer is emitted, because there is no published compliance program to point at. regulatory_note: >- A crypto-settled digital-goods reseller with an explicit no-KYC posture sits outside the regimes the catalog would normally probe for a payments provider (PSD2/FAPI/PCI). Recording that as an absence, not a failure — MyStars never takes fiat, never holds customer keys, and the funds path is a direct on-chain transfer between the payer and a treasury address.