SOLbin — External Review Report (Sanitized)
What this is
A factual snapshot of the externally reachable surfaces and of the security controls this team says it has implemented, produced on demand by the application itself.
What this is not
- Not an independent audit. It is produced by the same team, on the same platform, as the application it describes.
- Not a certification. There is no SOC 2, ISO 27001 or equivalent attestation behind it.
- Not a penetration test. Only the 7 probes below were exercised for real; everything else was not tested.
- Not a warranty. Statuses are a snapshot at the generation timestamp and can change.
Scoring policy
No composite score is published by this report. Each control carries its own status and an independent way to check it; a single number would invite a reader to treat unverified claims as verified.
Not verified — stated plainly
These areas are outside what this report establishes. A passing probe anywhere else in this document says nothing about them.
- [NOT VERIFIED] Signing paths
Not tested: Transaction construction, signing and key handling under adversarial input were NOT exercised.
Why not: Exercising them means producing and broadcasting real signatures, which cannot be done harmlessly inside a report run.
How to verify: Have an independent party try to sign and submit a transaction with tampered inputs (wrong recipient, altered amount, unexpected message) and confirm the app refuses before signing. - [NOT VERIFIED] Autonomous trading bots (excluded from the probes by design)
Not tested: No bot strategy, entry, exit, stop-loss or failover path was started, driven or observed by this report.
Why not: Deliberately excluded from the probe set: starting a bot opens live positions and moves real funds, so a probe there would be a trade, not a test.
How to verify: Rehearse the bot logic in a paper-trading or devnet configuration, or have an independent reviewer audit the strategy code and its failure handling. - [NOT VERIFIED] Account-to-account data isolation
Not tested: Whether one account can read or modify another account's records was NOT tested.
Why not: Proving isolation needs a second account's real session; a report endpoint running with elevated privileges cannot show what a normal user is denied.
How to verify: Sign in as a second, unprivileged account and request the first account's records, wallets and payouts. Expect empty results or a refusal.
The 7 probes cover public, read-only surfaces only: an anonymous call, a forged origin, a malformed input, a crawler policy and a sitemap. They do not touch signing, bots or per-user records.
Corrections — claims withdrawn from earlier material
- A published composite security score (for example 94/100) as evidence of posture.
Reason: Withdrawn. The line items behind it did not reconcile with the stated total, and no scoring method was published, so the number could not be checked — the exact problem it was meant to solve. - Audit material described as conducted by a named security engineering function.
Reason: Withdrawn. That material was self-produced by the application's own team, not by an independent firm.
What is not in this file
- Personal data included: no
- Secrets or API keys included: no
- Wallet addresses included: no
- User identifiers included: no
- Values removed by the output guard: 0
- API keys, provider tokens and webhook secrets (existence is reported as a boolean at most; values are never read into the report).
- Private keys, seed phrases and encrypted keystore blobs.
- Wallet addresses and transaction signatures.
- User identities: names, emails, handles, roles and per-user records.
- Client IP addresses, request logs and ban lists.
- Infrastructure detail: RPC provider endpoints, proxy inventory and internal file paths.
- Volume metrics: registered users, wallets created and revenue figures.
Application snapshot
Custody: Self-custody. Keys are generated and encrypted on the user's device; the server never receives a seed phrase for user wallets.
Chains: Solana (SOL), BNB Smart Chain (BNB), Bitcoin (BTC), Ethereum (ETH), Avalanche C-Chain (AVAX), Tron (TRX), Robinhood Chain (ETH)
Backend model: React single-page front end; data and all external calls go through authenticated backend endpoints on a managed platform. Privileged operations are separated behind an admin role.
- Credential configured: chain RPC credentials - yes
- Credential configured: admin IP allowlist - yes
- Credential configured: origin allowlist - yes
- Credential configured: custodial wallet master key - yes
Booleans only. A 'yes' means the credential is configured as a platform secret, not that this report read, validated or transmitted it.
Verification probes (run live when this report was generated)
price-feed-anonymous — Live price feed refuses anonymous callers
Request: POST https://solbin.fun/functions/priceOracle with an empty body and no session
Expected: HTTP 401 — the metered provider call behind it must not be spendable by an anonymous caller
Observed: HTTP 401 in 255ms (body: "Unauthorized")
origin-enforcement — A foreign site's origin is refused
Request: POST https://solbin.fun/functions/priceOracle with 'Origin: https://attacker.example'
Expected: HTTP 403 — a page on a domain outside the allowlist must be refused, and refused before authentication is even considered
Observed: HTTP 403 in 167ms (body: "Unauthorized origin")
wallet-attestation-minimal — Public wallet attestation discloses membership only
Request: POST https://solbin.fun/functions/verifySolbinWallet with a well-formed, unregistered address
Expected: HTTP 200 and a body whose fields are limited to membership flags — no address, role, balance or profile data
Observed: HTTP 200 in 350ms; response fields: registered
input-validation — Malformed input is rejected, not processed
Request: POST https://solbin.fun/functions/verifySolbinWallet with a truncated, invalid address
Expected: HTTP 400 with a rejection reason, and no on-chain lookup attempted
Observed: HTTP 400 in 222ms (reason: "Invalid Solana address")
crawler-policy — Crawler policy keeps the backend API out of the index
Request: GET https://solbin.fun/robots.txt
Expected: HTTP 200, a disallow rule for the backend API, and a sitemap directive
Observed: HTTP 200 in 4ms; backend API disallowed: yes; sitemap directive: yes
public-sitemap — Public sitemap is served and lists crawlable pages
Request: GET https://solbin.fun/functions/sitemap
Expected: HTTP 200 and XML beginning with <urlset that lists at least one URL
Observed: HTTP 200 in 347ms; <urlset> present: yes; listed URLs: 35
admin-gate-anonymous — A privileged endpoint refuses an anonymous caller
Request: POST https://solbin.fun/functions/grokAI with no session
Expected: HTTP 401 before any work — no model call, no data, no side effect
Observed: HTTP 401 in 248ms (body: "Unauthorized")
Controls
price-feed-anonymous (External surface)
Claim: Live price data is not served to anonymous callers; every price answer costs a metered provider call.
How to check: Reproduced by this report: see the probe of the same id.
origin-enforcement (External surface)
Claim: Requests are accepted only from the application's own domains: a page served from any other origin cannot call the backend, even unauthenticated.
How to check: Reproduced by this report: a request carrying a foreign Origin header was refused.
wallet-attestation-minimal (Data disclosure)
Claim: The public wallet-attestation endpoint answers with membership flags only, so it cannot be used to profile a wallet it does not recognise.
How to check: Reproduced by this report: the observed response field names are listed in the probe.
input-validation (Input handling)
Claim: Malformed input is rejected with a reason before any provider call is paid for.
How to check: Reproduced by this report: a truncated address was rejected with HTTP 400.
crawler-policy (Crawler exposure)
Claim: Search crawlers are directed to public pages only: the backend API is disallowed, the public sitemap stays reachable.
How to check: Reproduced by this report: both the policy file and the sitemap were fetched live.
credentials-externalised (Credential handling)
Claim: Provider credentials are held as platform secrets rather than in application source.
How to check: Presence only — this report reads whether each credential exists, never its value. Configured at generation time: chain RPC credentials yes, admin IP allowlist yes, origin allowlist yes, custodial wallet master key yes.
admin-gated-operations (Access control)
Claim: Privileged operations — trading-bot cycles, payouts, AI completions, treasury and vault wallets — require an authenticated session with the admin role and answer 401/403 otherwise.
How to check: Reproduced by this report against the shared admin gate on an AI path, which refused an anonymous caller before doing any work. Payout, treasury and bot-execution paths use the same gate but were deliberately not called anonymously: if a gate were wrong, that call would move real funds.
abuse-limits (Abuse resistance)
Claim: Request handling is rate-limited per user, per IP and globally, with escalating cooldowns and automatic bans after sustained violations.
How to check: Send repeated identical requests from one client and observe 429 responses, then a 403 once a ban is recorded. Deliberately NOT probed by this report: a burst test can auto-ban the address the probes come from, which would take the site's own reporting offline.
bot-honeypot (Bot containment)
Claim: Hidden honeypot fields detect automated form submissions and blacklist the source address.
How to check: Deliberately NOT probed by this report: probing it would blacklist the address the probe came from. Verify by submitting the hidden field from a throwaway client.
keystore-encryption (Key custody)
Claim: Wallet keystores are encrypted in the browser before leaving it, and stored only as ciphertext.
How to check: Inspect a stored wallet-backup record: only an encrypted blob and public addresses are present, never key material.
rpc-indirection (Provider exposure)
Claim: Chain RPC traffic is proxied server-side; the browser receives no provider endpoint or provider key.
How to check: Open the browser network inspector during a balance refresh: requests go to the app's own proxy routes, never to a provider host.
record-level-access (Data isolation)
Claim: One account cannot read or modify another account's records.
How to check: Ask a second account to request the first account's records: the expected answer is an empty result or a refusal. This report cannot perform that check — it holds no second user's session, and an endpoint running with elevated privileges cannot prove what a normal user is denied.
signing-and-bot-paths (Value-moving paths)
Claim: Transaction signing, key handling and the autonomous trading bots behave safely under adversarial conditions.
How to check: Not exercised here: driving these paths executes live on-chain transactions and moves real funds, so it cannot be done as part of a report. This is exactly what an independent penetration test is for.
independent-assurance (Independent assurance)
Claim: A third-party security audit, penetration test, or bug-bounty programme exists for this application.
How to check: None on record. This document does not substitute for one, and no such claim should be inferred from it.
Summary (arithmetic shown)
| Verified | Configured | Not verified | Total |
|---|---|---|---|
| 6 | 5 | 3 | 14 |
Check: 6 + 5 + 3 = 14 (matches the total)
What this report cannot prove
- Self-produced: the producer controls the code it describes, so nothing here is independent evidence beyond the 7 reproduced probes.
- Coverage: the probes exercise 7 externally reachable behaviours, including a forged origin, a malformed input and an anonymous privileged call. They are hygiene checks, not a penetration test.
- Record-level access rules: whether one account can read another's records was NOT tested. Proving that needs a second account's session, which a report endpoint cannot hold.
- Signing paths, key handling under attack, and the autonomous trading bots were NOT exercised: driving them executes live transactions and moves real funds.
- 'Configured' means the control exists in the code and is exercised in normal operation, not that it was adversarially tested. 'Verified' means only that the specific probe above passed.
- Rate limiting and the bot honeypot are deliberately unprobed: a burst test can auto-ban the probes' own source address, and a honeypot test would blacklist it outright.
- No bug-bounty programme, no third-party penetration test and no certification is claimed.
- Reproducing the probes confirms only what they test; a pass does not transfer to any other part of the application.
Reproduce it yourself
Anonymous price feed
curl -s -o /dev/null -w '%{http_code}' -X POST https://solbin.fun/functions/priceOracle -H 'Content-Type: application/json' -d '{}' # expect 401Wallet attestation
curl -s -X POST https://solbin.fun/functions/verifySolbinWallet -H 'Content-Type: application/json' -d '{"solanaAddress":"<any well-formed Solana address>"}' # expect a membership-only bodyCrawler policy
curl -s https://solbin.fun/robots.txt # expect the backend API disallowed plus a sitemap directivePublic sitemap
curl -s https://solbin.fun/functions/sitemap | head -c 200 # expect XML beginning with <urlsetAnonymous privileged call
curl -s -o /dev/null -w '%{http_code}' -X POST https://solbin.fun/functions/grokAI -H 'Content-Type: application/json' -d '{"prompt":"x"}' # expect 401 with no sessionForged origin
curl -s -o /dev/null -w '%{http_code}' -X POST https://solbin.fun/functions/priceOracle -H 'Content-Type: application/json' -H 'Origin: https://attacker.example' -d '{}' # expect 403Malformed input
curl -s -X POST https://solbin.fun/functions/verifySolbinWallet -H 'Content-Type: application/json' -d '{"solanaAddress":"shortinvalidvalue"}' # expect 400 with a rejection reasonEnd of report. Produced by SOLbin. Not an independent audit.