The entire developer documentation surface is five pages — landing plus four doc pages — describing a multi-chain non-custodial sweep protocol with live contracts on 8 networks. The docs read cleanly but the technical depth required to safely interact with the EVM sweep contract (ABI, events, errors, allowlisted routers, approval flows) is entirely absent, and the "Developers" section advertised on the marketing site does not exist.
1. "Developers" section advertised on marketing site does not exist (critical)
Problem: The marketing site's primary navigation contains a "Developers (Soon)" link, and the marketing copy frames Sweepr as "a protocol" with "smart contracts… fully verifiable on-chain." However, the entire docs surface (per sitemap.xml) contains only 5 URLs: /, /docs, /docs/contracts, /docs/flow, /docs/safety. There is no developer reference, no SDK, no integration guide, no ABI, no contract source link, and no API documentation anywhere.
Consequence: Developers arriving from the marketing site expecting a developers portal find a 4-page product overview instead. Anyone wanting to integrate, audit, or programmatically call the published sweep contract addresses has nothing to go on — and "Soon" has no timeline, no waitlist, no GitHub link, no contact path.
The fix: Either remove the "Developers (Soon)" promise until something ships, or publish a minimum-viable developer page with contract ABIs, deployed addresses (already public on /docs/contracts), event signatures, and a "report an issue" channel. State an expected timeline.
2. Live sweep contracts published with no ABI, no verified-source link, no allowlist (critical)
Problem: The docs list 8 live contract addresses (Base, Monad, Ethereum, BNB, Avalanche, Polygon, Optimism, Arbitrum) and instruct users to "compare the spender shown in the wallet prompt with the Sweepr contract address." Each address links to a network explorer ("Click an address to open it in the network explorer") — but no link confirms verified source on that explorer, and the docs themselves expose no ABI, no function signatures, no event signatures, and no description of the router allowlist. The page states the contract "executes allowlisted router calls" — the allowlist is never disclosed.
A user is told to verify the spender — but cannot verify what the spender does. An integrator cannot decode events or build on top. A security reviewer must manually pull each address from each explorer and confirm verification status one by one. The "wallet-owned, user-signed" assurance depends on a contract whose behavior is described only in prose.
Code verification
Runtime snippet checks
Run the public examples from this audit in an isolated sandbox and attach the pass, fixed, skipped, and failed counts to the report.
The fix: Publish the ABI for the V4 / Permit2 contract directly in docs. Link to verified source on each explorer (not just the address page). List the router allowlist per chain. Document the events emitted on a successful sweep so wallets and integrators can decode them.
3. Same contract address shown on 4 chains — no explanation, easy to misread as a typo (significant)
Problem: The address 0x64fF60c4F3E022A7F9D64eDE19DFFA79b4555c58 is listed identically for Avalanche, Polygon, Optimism, and Arbitrum (4 chains). Nothing in the docs explains why — no mention of CREATE2 deterministic deployment, no note that this is intentional, and no warning that users verifying the spender will see the same string on four networks.
Consequence: Two failure modes. (1) A cautious user assumes a copy-paste error in the docs and loses trust in the table. (2) A less cautious user develops the habit of approving "the usual 0x64fF... address" and won't notice if they're on the wrong network with a mismatched contract. Both undermine the very "compare the spender" guidance on the same page.
The fix: Add a one-sentence note: "The same contract address is intentional across Avalanche, Polygon, Optimism, and Arbitrum due to deterministic deployment. Always confirm the active chain in your wallet matches the network shown in Sweepr." Better: surface the deploy salt or factory address for independent verification.
4. llms.txt and llms-full.txt return the homepage HTML, not LLM-formatted text (significant)
Problem: Both URLs respond with the rendered Docusaurus homepage HTML (the same "Sweep dust into value" hero markup), not the plain-text llms.txt format. The file exists at the URL but is not a valid llms.txt — it's the SPA shell catching the route.
Consequence: AI coding agents that probe /llms.txt will get a chunk of marketing copy instead of structured doc URLs. They cannot efficiently index the four real doc pages. For a product whose pitch — "scan, route, sign" — is exactly what an agent might want to wire into a wallet workflow, this is a silent agent-indexing failure.
The fix: Either serve a proper llms.txt (list of the four doc URLs + landing, with one-line descriptions per the llms.txt spec) or remove the route so probes get a clean 404. If using Docusaurus, configure a static plugin so /llms.txt is served as text/plain.
5. robots.txt returns homepage HTML — no sitemap directive, no crawl rules (significant)
Problem:/robots.txt returns the SPA homepage HTML, not a robots file. There is no User-agent, no Disallow, no Sitemap: directive pointing to the existing /sitemap.xml. The sitemap exists and is valid, but crawlers following the standard discovery path won't find it.
Consequence: Search engines and doc crawlers that look for /robots.txt first see HTML masquerading as a robots file, may discard it as invalid, and miss the sitemap pointer. Combined with the broken llms.txt, machine discoverability of the docs is degraded.
The fix: Serve a real robots.txt with at minimum User-agent: *, Allow: /, and Sitemap: https://docs.sweepr.co/sitemap.xml.
6. Marketing site contradicts docs on aggregator IP and batching (significant)
Problem: Two specific gaps between marketing and docs:
The marketing site touts a "Proprietary Swap Aggregator." The docs /docs/contracts describe routing as "Jupiter" on Solana, "Multi-DEX aggregator, Odos, EVM routers" on Base, and "Odos / KyberSwap-backed routes" on Monad. These are third-party aggregators, not proprietary.
The marketing site says "All transactions are batched and routed through our proprietary aggregator." The docs /docs/flow say EVM uses "EIP-5792 batch calls where supported, sequential fallback otherwise" — so batching is conditional, not universal.
Consequence: A developer evaluating the protocol's IP and execution guarantees gets opposite stories. "Proprietary aggregator" is a meaningful technical claim; "we wrap Jupiter, Odos, and KyberSwap" is a different value proposition. Integrators making routing assumptions on the marketing claim will be wrong.
The fix: Reconcile the language. If there's a proprietary layer on top of Odos/Jupiter/KyberSwap, describe what it actually does (route selection logic? quote stitching?). Replace "All transactions are batched" with "Batched where the wallet supports EIP-5792; sequential otherwise."
7. Marketing "Safety Layer" features have no counterpart in the docs (significant)
Problem: The marketing site claims two concrete safety features:
"Suspicious tokens are flagged before execution." The Security Model on /docs/safety lists checks for route availability, estimated output, minimum receive, price impact, slippage, native gas balance, and provider/aggregator errors — but never describes a token-reputation or suspicious-token flagging mechanism. There is no list of signals used, no source of the reputation data, and no description of what "flagged" looks like in the UI.
"Slippage protection with user override controls." The docs describe slippage as a check but never document the override UX, default thresholds, or how a user changes them. /docs/flow mentions slippage as a preview field; /docs/safety says "Slippage protects the minimum acceptable output" — neither mentions override.
Consequence: An integrator or security reviewer cannot reason about these advertised features. Users cannot predict when a token will be flagged, why, or whether they can override. The marketing makes promises the docs do not contract.
The fix: Either document the suspicious-token signal set and the slippage override UX (default %, max %, where the control lives, what happens on override) on /docs/safety, or remove the marketing claims until they are documented.
8. "Sweepr should warn, skip, or block" — three different unspecified behaviors (significant)
Problem: The Security Model says "If a token cannot be evaluated safely, Sweepr should warn, skip, or block it." The Sweep Lifecycle says "If a token cannot be routed cleanly, it should be skipped or blocked instead of being silently included." Neither page specifies which condition triggers warn vs. skip vs. block, what the user sees in each case, or whether the user can override a "blocked" state.
Consequence: Users can't predict whether a token will appear in the preview, be greyed out, or be excluded silently. The "warn/skip/block" trichotomy looks like a real safety mechanism but is described as aspirational ("should") with no observable contract.
The fix: Define the three states explicitly. List which conditions map to each (e.g., "no route quote → block; price impact > X% → warn but selectable; insufficient native gas → skip with badge"). State whether block is overridable.
9. Core integration terms used without definition (significant)
Problem: Several load-bearing terms appear with no definition or link to a primary source:
Reown AppKit (/docs/flow step 1): named as the EVM connector but not explained or linked.
EIP-5792 (/docs/flow step 5; /docs/contracts): referenced as the batch-call mechanism with no one-line definition or link to the EIP.
Permit2 (/docs/contracts): the section is titled "V4 / Permit2" and Permit2 is mentioned in "Contract Behavior" but never defined.
Paymaster (/docs/flow step 5: "Base mini app: Can use paymaster support when configured"): not explained — no description of what sponsorship means for the user, when it applies, or who pays.
"Mini app" and "embedded" contexts (/docs overview, /docs/flow step 1): referenced as separate execution surfaces ("Embedded and mini app contexts are handled separately") but neither is defined.
Consequence: A reader who doesn't already know Wagmi/Viem-era EVM tooling cannot understand the lifecycle. An agent ingesting these docs has no way to resolve "Reown AppKit" or "EIP-5792" to a concrete capability. The docs read as written for an audience that already knows the stack.
The fix: Add one-line definitions and link to canonical sources: link Reown AppKit to its docs, EIP-5792 to the EIP page, Permit2 to Uniswap's spec, paymaster to ERC-4337 / Base App docs. Add a sentence each defining "mini app" and "embedded" execution surfaces.
10. Fee mechanism on Solana undocumented; "default" in EVM fee description unexplained (minor)
Problem: Docs say "The app presents a 2% service charge in the sweep preview. On EVM sweep contracts this is represented as 200 basis points by default." "By default" implies the rate can vary, but the docs never explain when or how. Separately, the Solana path (which uses Jupiter, not a Sweepr sweep contract) is never described in terms of how the fee is actually collected — Jupiter's referral/fee mechanics differ from a contract-side bps deduction.
Consequence: A user can't tell whether 2% is universal or a default that may change per token, per chain, or per route. Solana users in particular have no description of how the fee is taken (separate transfer, Jupiter referral account, etc.).
The fix: Clarify whether 2% is universal across all chains and assets today. If "default" was meant to convey "configurable in the contract but currently 200 bps on all live deployments," say that. Document how the fee is collected on Solana.
11. Hard dependency on Helius and Alchemy with no graceful-degradation note (minor)
Problem: The docs state: "On Solana, token discovery and enrichment are powered by Helius. On Base, Sweepr uses Alchemy for balance discovery." Both are single-vendor RPC/data providers. The docs never address what happens if either is down, rate-limited, or returns partial data. Sweepr's core promise — "discover wallet dust" — depends entirely on these providers on its two flagship networks.
Consequence: Users on Solana or Base whose scan returns zero or partial results have no way to know whether the wallet truly has no dust or the provider is degraded. Integrators have no fallback contract to rely on.
The fix: State the failure mode (e.g., "If Helius is unavailable, Sweepr displays an error rather than partial results") and note any retry/backoff or secondary provider behavior.
12. V3 contracts mentioned but never explained (minor)
Problem: The page says: "V3 contracts are not active in the current public sweep flow. They are intentionally not listed as active spender contracts here." V3 is never introduced or defined elsewhere in the docs. A reader has no context for why V3 exists, what changed in V4, or why this needs to be called out.
Consequence: The note reads as an internal artifact leaked into public docs. Users who do encounter a V3-era approval on-chain (e.g., from a historical wallet position) have no guidance on how to revoke it or what address to look for.
The fix: Either remove the V3 paragraph or add a short note: "Earlier V3 sweep contracts existed at [addresses]. If your wallet has an outstanding V3 approval, revoke it at [tool]. The current flow uses V4 / Permit2 exclusively."
13. History storage warning buried in the last sentence of a lifecycle page (minor)
Problem: "History is browser-local, so clearing site data can remove it." This is the only mention of sweep history persistence in the entire docs surface, and it sits at the very bottom of one page. There is no mention of exporting transaction history, no link to view past sweeps from on-chain events, and no note that incognito/private browsing wipes it on close.
Consequence: A user who completed sweeps last week and now wants to find them after clearing cookies has lost the record from Sweepr's UI. They'd have to reconstruct from explorer activity — except the docs don't explain how to do that either (no event signatures, no per-tx tag pattern).
The fix: Surface persistence behavior earlier (e.g., on the landing page or in the Security Model). Add a one-line note: "To recover historical sweeps after clearing site data, look for Swept events emitted by the Sweepr contract on your active network." Better: add an export button or an on-chain query path.
What they do well
Honest framing of non-custodial behavior — /docs/safety includes a clear, repeated "if the wallet prompt does not match the preview, cancel" instruction.
Explicit per-chain routing table — /docs/contracts is short but unambiguous about which discovery / routing / execution path each chain uses.
Compact and consistent terminology within the docs — "dust", "sweep", "route availability", "service charge" are used the same way across all four pages.
Top 3 recommendations
Publish a real developer surface before linking to "Developers (Soon)" — at minimum: ABI for the V4 contract, links to verified source on each explorer, the router allowlist per chain, and the events emitted.
Reconcile marketing vs. docs language — "proprietary aggregator," "all transactions batched," "suspicious tokens flagged," and "slippage override controls" on the marketing site all lack technical backing in the docs. Either document the mechanisms or remove the claims.
Fix machine discoverability and define core terms — serve a real robots.txt and llms.txt (both currently return SPA HTML), and add one-line definitions for Reown AppKit, EIP-5792, Permit2, paymaster, and mini app / embedded contexts so the docs are readable to someone (or some agent) not already inside the Wagmi/Viem ecosystem.