Security
How access is actually decided, what the product refuses to trust, and where the limits are. The last section is the one that matters: the known weaknesses, stated by us rather than found by you.
Last updated 24 September 2026 · Operated by Totym · hello@totym.io
Where a gate decision is made
On the server, always. A gate reads the chain directly through a node provider and compares the result against the rule the creator set. The browser is told the outcome; it is never asked for it.
This matters because the opposite is common and looks identical from the outside. A gate that hides content in the browser has already sent that content to the browser, where anybody can read it with developer tools. Hiding is not protecting.
Holding a token is not the same as proving you do
Our public lookup endpoint answers whether a given address holds enough of a token. That is a true answer about an address — and it is not an access decision, because the address came from whoever asked. Anyone can copy a large holder's address from a block explorer and be told it qualifies.
So every response from that endpoint carries verified: false, permanently and by design. It is the endpoint stating its own limit.
To establish that somebody controls an address, we ask their wallet to sign a challenge this server issued: a single-use number, valid for three minutes, spent whether or not the signature turns out to be correct. A correct signature returns a short-lived token bound to that address, and the endpoint that answers access questions with a token has no address parameter at all. Naming an address achieves nothing there, because there is nowhere to name it.
What we never hold
Your keys. Totym has no custody. It cannot move, freeze, or recover your assets, and no support request can change that.
Your password.There isn't one. Sign-in is handled by our identity provider using email, Google, or a wallet signature.
Some specifics, for people who want them
Database access is closed by default: row-level security is enabled with no policies granted to anonymous callers, so the anonymous key reads nothing. Every read and write goes through server code holding a service credential.
Session tokens are signed with HMAC-SHA256 and compared in constant time. Challenges are consumed by a single conditional update, so the same one cannot be redeemed twice even under concurrent requests.
Endpoints are rate limited individually, with the tightest limits on the one unauthenticated route that writes.
When we cannot complete a check — a node is unreachable, a provider is down — we return an error, never a denial. Telling a real holder they do not hold something is a worse failure than telling them to try again.
Known limits, stated plainly
The old package is still on npm, and still unverified. @buildnimbus/sdk@0.1.0 calls the public lookup endpoint and accepts a wallet address supplied by the page, so a gate built with it can be opened by anyone who supplies a qualifying address. It will not get further releases. The verified path now ships in @totym/sdk — proveWallet() for the signature exchange, and @totym/sdk/server for a guard that runs before the response is built. If you integrated before, upgrading is the fix.
Gate components are still presentation. Even in the new package, hiding children in React removes them from the view and not from the response. The server guard is the part that withholds anything, and it has to run on your server.
Gate accuracy depends on third-party nodes. We read balances from node providers. If one returns stale data, a gate decision reflects that staleness.
Uploaded images are public. Community artwork is stored on IPFS and cannot reliably be withdrawn once distributed.
There is no bug bounty yet. We will still credit you.
Reporting something
Email hello@totym.io with enough detail to reproduce it. If it is sensitive, say so in the subject line and we will reply with a way to send it privately.
What we ask: do not test against other people's communities or wallets, do not run anything that degrades the service for others, and give us a reasonable chance to fix it before publishing.
What we will do: acknowledge within a few days, tell you what we found, and tell you when it is fixed. If you would like credit here, you will get it.