koshelek.ru Docs

Appearance

Security ​

Key handling ​

  • Never ship an API key in client-side code. Anyone reading your app bundle can drain your CU budget and rate limits. Proxy RPC calls through your backend, or issue per-environment keys you can revoke fast.

    The RPC host sends no CORS headers — on purpose

    rpc.nodes.koshelek.ru doesn't allow cross-origin browser requests, so a fetch straight from a web page fails CORS by design. That's the rule above enforced in the gateway rather than left to good intentions: if it worked, your key would be in the page. Call the RPC host from your server. (The dashboard and management API hosts do send CORS headers — they use short-lived JWTs, not API keys.)

  • Environment variables over config files. Every snippet in these docs reads YOUR_API_KEY from the environment — copy that pattern.

  • One key per deployable unit. Separate keys for staging/production/CI make revocation surgical and usage attributable. Keys are free.

  • Rotate on suspicion, not on schedule. Create-new → deploy → revoke-old is zero-downtime (Authentication).

Blast-radius control ​

  • Project chain scoping — a compromised key for an ["eth"]-scoped project cannot touch your Bitcoin traffic (how to).
  • Projects as bulkheads — usage, quotas and keys are per project; split products or teams into projects rather than sharing one.

Account security ​

  • Enable TOTP 2FA or add a passkey in the dashboard (Settings → Security). Recovery codes are shown once — store them offline.
  • A passkey is tied to the dashboard domain it was created on — that is how browsers scope passkeys, not a platform setting. If you use the dashboard on more than one domain, add a passkey on each; Settings → Security shows which domain every passkey works on.
  • Review active sessions (GET /api/v1/auth/sessions) and revoke any you don't recognize; "log out everywhere" is POST /api/v1/auth/logout-all.
  • The audit log (Settings → Audit) records logins, key operations and project changes with timestamps and IPs.

What we do on our side ​

  • Keys are stored hashed; the plaintext exists only in the create response.
  • Revocation takes effect within seconds, at two layers: the gateway credential is deleted, and every proxy replica holds a push-updated deny-list that refuses a revoked key (401, JSON-RPC -32012) even if the gateway layer lags — a revoked key inside a batch kills the whole batch before anything runs.
  • TLS everywhere (Let's Encrypt, auto-renewed); plaintext HTTP is redirected (308).
  • RPC nodes are never exposed directly — every request passes the authenticated gateway and the metering proxy.
  • debug_* is disabled on /eth; expensive scan methods have per-plan budgets (Rate limits).
  • Every response carries X-Correlation-ID — quote it in support tickets so we can trace the exact request without you sharing payloads.

Signup & account protection ​

Account creation is rate-limited per source IP and screens out malformed and disposable-mail addresses. Depending on deployment configuration, signup may require a CAPTCHA, and creating your first API key may require confirming your email address first — follow the link we send on registration. These exist to keep the free tier usable for real users; they don't affect your API traffic once your key is issued.

Device check ​

The dashboard sign-up and sign-in forms also run a browser device check and send its result with the form. What that means concretely:

  • What is computed. Open-source FingerprintJS (MIT) hashes browser and device attributes into one pseudonymous identifier, plus BotD (MIT) flags automation (headless browsers, WebDriver). Both run in your browser.
  • What is sent to us. The resulting identifier, a confidence score, the bot verdict, and a fixed, small set of device characteristics used to recognize the same machine across browsers: graphics adapter name, OS platform and architecture, CPU core count, screen resolution class, timezone, language list, touch capability, which of a fixed 52-name font probe list rendered, and hashed canvas/audio values. No browsing history, no page content, no free-form enumeration of what is installed. A one-shot server nonce accompanies the payload so a recorded submission cannot be replayed.
  • What it is used for. Capping how many accounts one device may register (free-tier multi-account abuse), correlating devices that share a machine, and scoring sign-in risk — the strongest automatic consequence of a high score is an extra CAPTCHA, never a block. Operators see the linked accounts and every risk decision with its named reasons when investigating abuse. It is never used for advertising, never sold, and never shared with a third party — the check runs entirely on our own infrastructure, with no request to Fingerprint's servers.
  • If it doesn't run. Sign-up works without it unless the operator of your deployment explicitly requires it; the per-IP limits above still apply. A missing check is treated as "no signal", not as suspicion.
  • Retention. Associations are deleted with the account they belong to. The per-device registration counter and the device characteristics are kept without any account link, so deleting and re-creating accounts does not reset the quota.

This is a self-hosted platform: whether the check runs at all, and how strict it is, is a deployment setting (admin console → Rate Limits → Auto-protection).

Sending transactions ​

The platform never holds your private keys. Sign locally (ethers, bitcoinjs, xrpl.js, …) and submit the raw bytes via the chain's broadcast method. Treat any service that asks for a private key — including anything claiming to be us — as hostile.