SOLbin's Security Audit, Explained: Every Safeguard Behind Your Transactions

Safety Should Be a Document, Not a Claim

Every wallet says it's secure. Very few publish what was tested, what was found, what was fixed, and what was not covered.

SOLbin's audit is public — findings, code-level verification, score breakdown, and its own scope limits — one tap from the Security page in the app, or directly at /security-audit, where you can also download the raw markdown. This is the plain-English version.

The Six Findings — All Verified Fixed

The audit (Base44 Security Engineering, automated static analysis plus manual code verification across the multi-chain codebase) reopened six previously identified issues and confirmed each fix is active and enforced:

C-01 — Dogecoin burn isolation. Burned DOGE is sent to a provably-unspendable address, and that sink is kept separate from the platform fee vault. Burned coins are destroyed — never quietly rerouted. An OP_RETURN record is attached for the audit trail.

H-01 / H-02 — Zero-address rejection. Sending to address(0) on an EVM chain or Tron is a classic way to lose funds forever. The check is the very first gate, running before format validation, on every EVM chain and Tron.

H-03 — Contract existence validation. Before a token batch is encoded on BNB Chain, the app confirms the token contract actually has deployed bytecode. If it doesn't, nothing gets built — no gas burned on a token that doesn't exist.

M-01 — Exact token math. High-decimal tokens (up to 18 decimals) are converted with integer-only arithmetic instead of floating-point math, eliminating rounding truncation and overflow risk on transfers.

M-02 — Fail-closed balances. If a balance oracle is down, times out, or errors, the transaction is refused. Not guessed, not passed through — refused, on every chain handler, with the denial written to the audit log.

M-03 — Tron ownership binding. Before any Tron signing, the loaded keypair's address must match the transaction owner. A mismatch throws before a transaction is even created.

The Gates Every Transaction Passes

Beyond the six fixes, the report documents the architecture itself:

• Single-use HMAC nonce. Every signing request requires an HMAC-SHA256 nonce with a 30-second window, tracked single-use in the database — so a captured request can't be replayed, even across separate server instances.
• A 5-layer server-side validation gate. Global kill-switch, per-user cooldown, server-resolved fee vault and percentage, value caps (batch size, per-transfer and batch totals, fee ceiling), and balance re-verification — all before your device signs anything.
• Server-authoritative fees. Fee addresses and percentages are resolved on the server from admin config; values supplied by the client are discarded. Fees ride inside the same atomic transaction as the transfer, so a fee can't be silently skipped.
• Non-custodial keys. Keys are encrypted on your device (AES-256-GCM, derived from your PIN). The server never sees, holds, or transmits them — and cannot sign without you.

On Smart Contracts: What's Actually at Stake

This is the question every user should ask, so here's the straight answer.

SOLbin does not deploy a smart contract that holds your money. It's a self-custody wallet: your funds sit in addresses that only your keys control. There is no SOLbin deposit contract to drain, no upgradeable proxy to hijack, and no admin key that can move your balance.

That custody model is exactly why the audit focuses where it does. The contracts in play when you use SOLbin are standard token contracts (SPL, BEP-20) and third-party DEX programs — not ours, and not part of this report. What is ours, and what was audited, is the pipeline that validates, builds, and signs every one of those interactions. That's the part of the system where a bug could actually cost you money.

When a wallet or exchange does hold customer funds inside a contract, that contract becomes the entire risk surface — which is why custodial designs need audits the size of books. SOLbin removed that surface rather than hiding it behind a logo.

We're not going to label this a smart-contract audit, because that would be inaccurate. What it is: a code-level security audit of the transaction pipeline on a non-custodial wallet, published in full.

What the Audit Excludes

An honest report states its limits, and this one does:

• Trading bot modules and autonomous swarm subsystems were explicitly out of scope. The wallet's transaction pipeline is audited; the bots are not covered by this report.
• Multi-signature and threshold signing were out of scope — they aren't part of SOLbin's architecture.

We'd rather tell you what isn't covered than imply coverage we don't have.

How to Verify It Yourself

• Read the report at /security-audit — every finding, the code-level verification, the score breakdown, and the scope statement. Download it as markdown and keep a copy.
• Check the claims that are on-chain. The Dogecoin burn sink is publicly visible and provably unspendable. Fee routing is atomic and inspectable per transaction.
• Scan your own wallet. Security → Audit runs a read-only wallet health scan for reclaimable rent, dust balances, and spam tokens. It's a health check, not the audit — it never signs anything and never touches your keys.
• See the whole surface, not just our summary — the report lists file-level verification for each fix, including the exact functions and gates involved.

Security isn't a badge on a homepage. It's a document you can read, a gate you can trace, and a claim you can check.

This is ours.