# Audit prompt — user perspective (v2.0) **What it is for:** anyone can hand this text, together with the source code (or the APK), to an independent auditor — human or AI model — and get a report that answers the questions a non-technical user would ask before installing an app that will hold their real money. **Prompt version:** 2.1 — 2026-10-20 (replaces 1.0; see §1.1 and §1.2) **Application:** 0x2ALL (Android, local key custody, Hyperliquid) **What changed from 1.0 to 2.0:** the scope explicitly declares the owner's design decisions (§1.1). They are **not** findings: the auditor verifies that they are implemented as declared and describes them in their own section (§4, item 2b). The report is also forbidden from publishing operational custody values (addresses, amounts, credentials) (§1.2). --- ## 0. Your role You are an independent security auditor. Your client is a **user who has never heard of the developer**: they found a website, the site offers an APK, and the APK will store the private key of a wallet with real money. The developer is anonymous. There is no company, no registration number, no app store, no public track record. Your job is not to praise the architecture. It is to answer, with evidence, one question: > **If I install this app and deposit money, can it steal my funds, charge me more than > declared, or do something malicious on my device?** You are skeptical by default. The burden of proof is on the developer, not on you. --- ## 1. Evidence rules 1. **No claim by the developer counts as proof.** README, website, code comments, previous audit documents and commit messages are allegations, not evidence. They may be cited, but each one must be confirmed in the code, in the binary or in the output of a command. 2. **Every answer needs primary evidence:** `file:line`, reproducible command output, an APK field or a network record. Without it, the answer is "not verified" — and "not verified" is an acceptable answer; inventing is not. 3. **Negative evidence is mandatory.** For every vector you declare absent, say what you searched for and show that the search came back empty (the command and the result). "I found nothing suspicious" without the recorded search proves nothing. 4. **Do not change the code.** This is a report-only job. If you find a defect, describe the defect and the suggested fix; do not fix it. 5. **Separate the mechanical from the judgment.** Hashes, permission lists, domain lists and signature destinations are facts anyone can verify. "The code is well written" is judgment — say that it is judgment. ### 1.1 Declared design decisions (out of scope as findings) The owner declares the decisions below as **conscious design choices** with accepted risk. They **cannot** be classified as a finding, vulnerability or rejection. What you **must** do with each one: - verify that it is **implemented exactly as declared** (with `file:line`); - describe the effect on the user and the accepted risk, in plain language; - if the implementation **contradicts** the declaration, that is a finding — record and classify it normally. **DD1 — The address that receives the 2% fee is not published.** The fee goes to a fixed custody address embedded in the code , with no runtime setter and no network data able to change it. The literal address value appears neither in the app, nor on the website, nor in this report. Declared reason: reduce the exposure of the fee signers to physical coercion (*wrench attack*). Accepted risk: the destination is not verifiable from public text. **DD2 — The Keystore custody key is autonomous (no biometric binding).** The seed blob is encrypted with an Android Keystore AES key created with `setUserAuthenticationRequired(false)`, because the bot must decrypt the seed to sign the automatic profit withdrawal while the device is locked. Manual custody actions (reveal seed, send, withdraw, consolidate, offboard, delete) have a separate presence gate (biometrics → device credential → denial). Accepted risk: a rooted or compromised device exposes the seeds; it is not a remote vector. **DD3 — Automatic profit withdrawal (D12 policy).** When a position realizes a profit of US$ 22 or more, the app withdraws 50% of that profit to the user's own address; the other half stays on the exchange compounding the principal. The signature uses the master credential derived from the seed, without user presence. Accepted risk: the key custody must be available to the automated path (a consequence of D2). **DD4 — Sizing with 100% of equity and 10x–50x leverage.** Each position is sized on the wallet's total equity (margin + unrealized profit), using the asset's maximum available leverage (10x–50x), with distant targets (+30%, +90%, +210%…) and a stop that moves up to protect profit. Accepted risk: total or partial loss of capital is possible in a strong market reversal — it is declared in the app, in the Terms and on the website. > All four decisions concern **product risk and the owner's threat model**. A finding is > what contradicts what was declared, not what was declared. ### 1.2 What the report does NOT publish - Literal values of custody addresses, keys, seeds, credentials or any operational secret. Describe the **model** ("fixed custody address"), never the value. - A step-by-step reproducible attack recipe. Describe the class of the flaw, the impact and the suggested fix; the technical detail goes to the developer, not to the public page. This applies to the published report. It is still required to record **what** was found and **with which evidence** — omitting an existing finding is an automatic rejection (§3, item 8). --- ## 2. Questions the report MUST answer Answer each item with **YES / NO / NOT VERIFIED**, followed by the evidence. If the answer is "yes", say exactly where, where the money goes and who authorizes it. ### Group A — Money - **A1.** Does the app have any path that takes money from the user **beyond the declared 2% activation fee on each deposit**? (recurring fee, profit share, subscription, per-trade fee, tip, "donation") - **A2.** List **all** possible destinations of funds: on-chain transfers, exchange withdrawals, fee payment. For each one, state whether the destination is the user's own address, a declared fixed address embedded in the code, or something computed at runtime. Is any destination dependent on data received from the network? (Do not reproduce the literal address values — §1.2.) - **A3.** Can the fee be charged **twice** for the same deposit? (app restart, bot resume, reinstall, importing the same wallet, two wallets with the same seed, network failure before confirmation) - **A4.** Is there a backdoor, "developer mode", feature flag, remote configuration or server response able to change the **destination, amount or recipient** of an operation? Does the app obey any instruction coming from the network about where to send money? - **A5.** Does the app request a token **approval (approve/allowance)** at any point? If so, what is the approved limit and can a third party spend it? - **A6.** Do the seed or the private key **leave the device** on any path? (network, log, backup, clipboard, intent, external file, notification, screenshot) - **A7.** Can someone holding the APK extract the seed? Consider: rooted device, `adb backup`, external storage, logcat, memory dumps, APK repackaging. Relate this to **D2** (declared decision). - **A8.** Can the user lose funds through a path they did not explicitly authorize? Describe the worst realistic case and the worst adversarial case. Relate this to **D4** (declared decision). ### Group B — Malware / on-device behavior - **B1.** List **all** declared permissions and why each one is needed. Is any of them risky: SMS, contacts, calls, location, accessibility, device administrator, screen overlay, package installation, external storage reading? - **B2.** Does the app load code at runtime? (`DexClassLoader`, `PathClassLoader`, DEX/JAR download, `eval`, WebView with a JavaScript bridge, plugins) - **B3.** Which components are exported (`exported=true`)? What can a third-party app installed on the same device do with them? - **B4.** Is there any third-party library doing telemetry, analytics, ads, crash reporting or identifier collection? List all dependencies and what each one sends over the network. - **B5.** Does the app hide itself or resist removal? (fake icon, disappears from the app list, prevents uninstall, runs without a visible notification) - **B6.** Does the app detect root, emulator, debugger or device "fingerprint"? For what purpose, and where does that data go? - **B7.** Does the app update itself, install APKs or download code without the user's explicit consent? - **B8.** Is there a background service that keeps acting after the user stops the bot, closes the app or revokes a permission? ### Group C — Network and privacy - **C1.** List **exhaustively** the domains and IPs the app can contact. Is every destination necessary (exchange, network RPC, official site)? Is there any undeclared domain, analytics, third-party CDN or collection endpoint? - **C2.** Is all traffic HTTPS? Is `cleartextTrafficPermitted` set? Is there certificate pinning — and does it cover every host that receives sensitive data? - **C3.** What exactly goes in each request (public address, signature, order, app version)? Is any device, user or installation identifier sent? - **C4.** Does the website server record IP, user-agent or access time? What is retained and for how long? Is that declared in the privacy policy, and is the policy true when compared to the code? - **C5.** Does the privacy policy promise something the code does not do? (undeclared collection, undeclared retention, unlisted third party) ### Group D — Authenticity and integrity - **D1.** Is the distributed APK signed? What is the certificate (SHA-256 fingerprint), is it the same one published on the site, and does the file's SHA-256 match the declared one? - **D2.** Does the audited source code correspond to the distributed APK? How can the user verify that themselves? Is there a reproducible build, or at least the APK and certificate hashes published alongside the report? - **D3.** Does the app verify its own signature before sharing the APK (P2P distribution) or before updating itself? - **D4.** Does the audit report have a published hash? How does the user confirm that the text they are reading is the one that was audited and was not edited afterwards? ### Group E — Failure, loss and recovery - **E1.** What happens if the user uninstalls the app with an open position on the exchange? Is the money still accessible another way (seed, exchange website) or is it lost? - **E2.** If the device is stolen, what can the thief do? Is the seed protected by biometrics/device credential? Is the screen protected against screenshots? - **E3.** Is there any path where the app deletes a wallet that still holds funds, or considers "empty" a wallet with funds (balance read error)? - **E4.** What happens if the exchange is down, the connection drops mid-order or the response is lost? Can the app duplicate an order, duplicate a charge or end up in an inconsistent state? - **E5.** If the process is killed by the system with an open position, does the stop loss remain valid on the exchange? Does the app reconcile on return? --- ## 3. Automatic REJECTION triggers If **any** item below is true, the verdict is **REJECTED**, regardless of how good the rest is: 1. A funds destination **incompatible with the declared model** (fixed custody address embedded in the code, with no redirection by the user or by network data) — that is: a destination computed at runtime, an address coming from the network, or a path able to change the destination through configuration. 2. Seed/private key in network, log, backup or external file — on any path. 3. Accessibility permission, device administrator, package installation or screen overlay without a demonstrated functional justification. 4. Dynamic code loading from the network. 5. Telemetry, analytics or identifier collection not declared in the policy. 6. Duplicate charge of the fee for the same deposit in any reproducible scenario. 7. A report declaring "approved" without `file:line` evidence for each claim. 8. Omission of an existing finding to please the client. --- ## 4. Mandatory report format ``` 1. VERDICT: APPROVED | APPROVED WITH CAVEATS | REJECTED + count by severity (critical / high / medium / low / informational) 2. DIRECT ANSWERS (table: question | answer | evidence) 2b. DECLARED DESIGN DECISIONS (DD1–DD4) for each: what was verified (file:line) | implemented as declared? | effect on the user | accepted risk 3. FINDINGS (one per item): - ID, severity, title - Evidence (file:line or command + output) - Concrete impact on the user - Suggested fix - What could NOT be verified 4. LIMITATIONS: what the audit did not cover and why 5. REPRODUCTION: commands and steps so anyone can redo the verification 6. BINARY AND SOURCE EXAMINED: commit, version, APK SHA-256, certificate fingerprint, execution date/time ``` --- ## 5. Final rule A report that hides a finding to please the client is worse than no report at all: it transfers false confidence to the people who are about to deposit money. If the code does not support the promise, say so — and say where.