LEGAL · VERSION 2026-10-25
Security
SMeta is built so that there are no customer funds or private keys to steal. This page describes the controls that protect accounts and records.
Non-custodial architecture
SMeta never generates, receives or stores seed phrases or private keys, never operates wallets or smart contracts that receive customer funds, and never broadcasts transactions. Merchants register only public receiving addresses. Payments move directly from the payer's wallet to the merchant's wallet.
On-chain verification
An invoice is confirmed only after the software verifies a successful, solidified TRON transaction receipt from the canonical USDT TRC20 contract with a Transfer log for the exact amount to the registered address. There is no manual "mark as paid" path that bypasses chain verification. Each transfer is applied once, and late or ambiguous transfers require owner review with an audit trail.
Accounts and credentials
Passwords are stored as salted scrypt hashes. Session tokens, API keys, email links and support-chat tokens are stored only as hashes. Session cookies are HttpOnly and SameSite, and Secure in production. API keys are scoped, can expire and are shown only once. Account management requires a signed-in owner session, not an API key. Forms are protected by rate limits and optional Cloudflare Turnstile.
Webhooks
Webhook requests are signed with HMAC-SHA256 over the timestamp and raw body. Endpoints must use public HTTPS; private and loopback network targets are rejected and DNS results are pinned to prevent server-side request forgery. Failed deliveries are retried with exponential backoff for up to 72 hours.
Tenant isolation
Every query is scoped to the authenticated merchant. Public checkout pages show only what the payer needs and never expose merchant metadata, internal order identifiers or account details.
Reporting a vulnerability
Email the abuse and security contact published on the Legal page with a description, reproduction steps and impact. Do not access other users' data, disrupt the service or run automated scanning that degrades availability. We will acknowledge good-faith reports and will not pursue action against researchers who follow these rules.
Contact
Abuse, security and lawful authority requests: abuse@smetaledger.io. General support: contact form.