Wallet & security
How sign-in works, what we never ask for, and what to check.
Read what you sign#
The reservation flow asks for a message signature. It does not build or send a blockchain transaction. The message describes signing in to reserve or manage a bruh username and contains a one-time identifier and expiry.
bruh checks the signature against the public wallet address on the server. A connected address by itself is not enough to authenticate. A valid challenge can be used only once and expires after five minutes.
Things bruh never needs#
- Your wallet’s seed phrase or private key.
- A deposit to activate a username.
- A token approval or spending allowance for a reservation.
- Remote access to your device.
If a supposed support agent asks for any of these, stop. Use the support address linked from this site instead of replying to the message.
Check the domain#
Use https://joinbruh.com. The www address redirects to it. The sign-in message should identify this domain. A similar-looking address or a copied logo does not establish that a page belongs to bruh.
Reject an unexpected transaction prompt. The reservation flow requires only connection and a message signature. If you are unsure, cancel; you can start again later.
Sessions and shared devices#
After verification, the server creates a sign-in session in a secure, HttpOnly cookie. The browser uses it to manage your reservation. On a shared device, select Disconnect when finished and lock your wallet extension.
Deleting browser cookies signs you out but does not delete the saved reservation. Disconnecting is also different from revoking a wallet’s site connection; you can manage connected applications inside your wallet.
Limits and reporting#
Request limits and unique reservation rules reduce simple spam and conflicting claims. They do not prove a person’s identity or guarantee that one person cannot control multiple wallets.
To report a security concern, email [email protected]. Describe the affected page, steps to reproduce and expected behavior. Remove cookies, signatures, private keys and other credentials from screenshots or logs. Do not access other users’ data to demonstrate a problem.