// TINL_UAT_GUIDE · CHROME
Chrome / portal UAT — Step by Step
Read Part 1 first. It explains how this portal is arranged and why — an evaluator who does not know why the profile selector sits where it does cannot tell a correct result from a coincidence. Part 2 is the test itself: every step states what to enter and exactly what you should see.
This guide is only for the Chrome / portal Wallet Demo and Price Impact tabs (MetaMask and Phantom in the browser). It is not the Android mobile UAT. For the in-wallet WalletConnect path on an Android emulator or device, open the portal tab “Mobile UAT (Android)” and use TINL-Mobile-UAT-Guide-Android.pdf — do not mix steps from this guide into a phone run.
Download PDF saves TINL-UAT-Guide.pdf straight to your downloads — layout explanation first, then all 25 Chrome/portal steps, with space to record the result. It is generated from this same page, so the two can never disagree. Android steps are a different PDF on the Mobile UAT tab.
Part 1 — How this portal is laid out, and why
The portal is ordered top to bottom as a single argument: what this proves → who you are signing as → what policy is active → what you are about to trigger → what TINL decided → the permanent record. Each region below names its purpose and the reason it sits where it does.
Access is per-organisation and time-boxed. The countdown is visible at all times so a long evaluation session cannot silently expire mid-test and be mistaken for a product failure.
Wallet Demo and Price Impact are two independent bodies of evidence on the browser path. UAT Guide (Chrome) is this 25-step list (also openable in a new tab via Open Chrome guide). Mobile UAT (Android) is a separate track for the in-wallet demo app — different preconditions, different PDF, different release blockers. Do not run one guide’s steps against the other product surface.
Placed before anything clickable, because it states what this demo does and does not prove. This portal owns both the interceptor and the consent UI, so WARN and NORMALIZE are enforced end to end here; in the current extension build they are advisory. Reading it after forming an impression would be too late.
Connect sits first so every evaluator uses their own MetaMask/Phantom before reading address cards. The profile is the independent variable of the whole evaluation — re-running one scenario under a different profile is a one-click A/B.
Full addresses are editable and copyable. Account A is your connected wallet (auto-filled on connect; you may paste). Account B is the spender/delegate the approve scenarios point at — a counterparty, never something you sign from. Key material is never shown or returned by the API.
Forces Mode A, the embedded WebAssembly engine, with no server call. It is adjacent to the profile selector because outage behaviour is bound to the profile, not to a global setting.
Order follows this guide’s headline path: unlimited approve first. Each row has a ? control with plain English of what the test does and what A3E9 solved. Expected decisions are stated before you click.
Appears BEFORE the wallet's own dialog — that ordering is the entire product. It shows plain-English what TINL did, the decoded intent, the rule that fired, and for NORMALIZE the amount choice. If the wallet ever prompts first, the interception did not happen.
Bottom of the page, because it is the record of everything above it. HMAC-chained and scoped to your organisation, so it demonstrates tamper-evidence rather than just logging.
Before you begin
- MetaMask installed and unlocked, network Sepolia. Use YOUR own funded account (any evaluator’s wallet) — not a shared private key. Test ETH on Sepolia is required for scenarios that submit a transaction.
- Phantom installed and unlocked, network Devnet, YOUR own wallet with some test SOL. Optional if you are only running the EVM path.
- Your evaluator token.
- You connect wallets; you never import them. No step in this guide asks for a private key or seed phrase. If any screen does, stop and report it.
- Android demo wallet evaluators: stop here and switch to the Mobile UAT (Android) tab — this 25-step list assumes browser extensions, not the phone app.
Part 2 — The test, steps 1–25
Work top to bottom. Steps marked RELEASE BLOCKER are the two claims the product actually makes; a failure there stops the release regardless of anything else.
Establishes that you are in the TINL evaluator (not the HSM one) and that both wallets are CONNECTED, never imported. You are never asked for a private key at any point in this guide; if any screen asks, stop and report it.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 1 | Open the evaluator and sign in. | https://a3e9.com/tinl/evaluator — paste the evaluator token you were issued. | Portal loads at /tinl/evaluator/portal. Header shows your organisation name and a session countdown. Tabs: Wallet Demo, Price Impact, UAT Guide (Chrome), Mobile UAT (Android). Stay on this Chrome track for steps 2–25. |
| 2 | On the Wallet Demo tab, click Connect MetaMask (above the address cards) and approve in the extension. | MetaMask unlocked, network Sepolia, YOUR funded account (any evaluator’s wallet with test ETH). | Button changes to "Connected: <your address>". Account A on the editable EVM card fills with that address. No private key was requested. If you see “already pending”, the MetaMask popup is likely behind this window — open it via the extension icon, then the error clears on success. |
| 3 | Click Connect Phantom and approve. (Skip if you are only running the EVM path.) | Phantom unlocked, network Devnet, your own wallet holding some test SOL. | Button changes to "Connected: <your address>". Solana Account A fills from Phantom. Account B remains the counterparty only. |
First scenario card on the page is "1 · Approve UNLIMITED WETH spend" — start here. A blanket "safe" rewrite to zero is safe in the allowance sense but misleading in practice: the transaction still lands, still costs a fee, and grants nothing. TINL asks instead. Step 7 is the proof that the amount you chose is the amount that reaches the wallet.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 4 | Confirm Active profile is Retail — Strict. Click EVM card #1 'Approve UNLIMITED WETH spend' (use the ? for plain English). | Profile: Retail — Strict. Scenario: 1 · Approve UNLIMITED WETH spend. | TINL's own popup opens FIRST — before MetaMask. Decision: NORMALIZE. Rule: ERC20_UNLIMITED_APPROVE. Plain-English panel explains what TINL did. |
| 5 | Read the three amount options and their consequence text. | None — visual check. | Only this much (with an amount field) · Nothing · Everything it asked for (unlimited). Each states its own consequence. "Nothing" explicitly warns the transaction still costs a fee and the site's action will most likely fail afterwards. |
| 6 | Select 'Only this much' and type a specific amount. | Type: 25 | No validation error. The field accepts the value. |
| 7 | Click Approve. Read the amount MetaMask now displays. Release blocker | None — read the wallet's own confirmation screen. | MetaMask opens showing a spending cap of 25 — NOT unlimited, and NOT zero. The number in the wallet equals the number you typed. Reject in MetaMask; you do not need to spend gas. |
| 8 | Repeat step 4, this time selecting 'Nothing'. | Profile: Retail — Strict. Scenario: Approve UNLIMITED WETH spend. Option: Nothing. | MetaMask opens showing a spending cap of 0. This is the revocation case, not the trading case. Reject. |
BLOCK is the one decision TINL enforces outright against a hostile page: it refuses before the wallet is ever invoked. The check is not that you can cancel — it is that there is nothing to cancel.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 9 | Profile: Retail — Strict. Click Solana card #2 'Hand off SPL token account owner authority'. Release blocker | Profile: Retail — Strict. Scenario: Hand off SPL token account owner authority. | TINL popup shows BLOCK, rule SPL_AUTHORITY_CHANGE. Phantom NEVER opens. No signature prompt appears at any point. |
| 10 | Switch Active profile to 'Active DeFi User — Balanced' and click the same scenario again. | Profile: Active DeFi User — Balanced. Same scenario. | Same input, different decision: WARN instead of BLOCK. This proves the profile is the policy, not decoration. |
WARN asks you to proceed with full information. Read the scope note at the top of the Wallet Demo tab carefully: inside this portal WARN and NORMALIZE are enforced end to end, because the portal owns both the interceptor and the consent UI. In the current browser-extension build they are advisory against a hostile dApp, and the wallet's own confirmation screen is the real backstop. BLOCK is enforced in both.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 11 | Profile: Retail — Strict. Click EVM card #3 'Call an unrecognized function on WETH'. | Profile: Retail — Strict. Scenario: Call an unrecognized function on WETH. | TINL popup shows WARN, rule SELECTOR_UNKNOWN, with an explanation of what is unknown about it. |
| 12 | Switch Active profile to 'DApp Operator / Bot — Passthrough' and repeat. | Profile: DApp Operator / Bot — Passthrough. Same scenario. | ALLOW. An operator's tooling calls unfamiliar selectors constantly; only genuinely dangerous patterns still warn under this profile. |
| 13 | Re-read the scope note at the top of the Wallet Demo tab. | None — visual check. | It states plainly that BLOCK is genuinely enforced in the extension build while WARN and NORMALIZE consent are advisory there. It does not claim more than that. |
After proving TINL rewrites and blocks danger, confirm it still lets ordinary activity through. A tool that blocks everything is not a security control, it is an outage.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 14 | Profile: Retail — Strict. Click EVM card #4 'Send 0.01 test ETH → Account B'. | Profile: Retail — Strict. Scenario: Send 0.01 test ETH → Account B. | TINL popup shows ALLOW with plain-English explanation. MetaMask then opens for a normal transfer. Reject or accept — either is fine. The decision appears in the Live Audit Log. |
| 15 | Skim every scenario ? help and expected captions in both columns. | None — visual check. | Every scenario states its expected decision and has a ? with plain English of what A3E9 solved. You are checking TINL against a stated prediction, not a result it invents after the fact. |
Uses your own connected Phantom on devnet. Editable Account A is your wallet; Account B is the delegate/counterparty only. TINL decides before signing, so these steps demonstrate correctly whether or not your wallet already holds a token account for the test mint.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 16 | Profile: Retail — Strict. Click Solana card #1 'Approve UNLIMITED SPL token delegate'. | Profile: Retail — Strict. Scenario: 1 · Approve UNLIMITED SPL token delegate. | TINL popup shows NORMALIZE, rule SPL_UNLIMITED_APPROVE, with the same three amount options and plain-English explanation. |
| 17 | Choose 'Only this much', enter an amount, and Approve. | Type: 10 | Phantom opens showing the capped approval rather than an unlimited one. Reject. If the amount field asks for raw units, that means this token's decimals could not be read — it says so rather than guessing. |
| 18 | Click Solana card #3 'Send 0.1 test SOL → Account B'. | Profile: Retail — Strict. Scenario: Send 0.1 test SOL → Account B. | ALLOW. A plain transfer of your own funds is not a delegation risk. |
TINL ships two co-equal transports. Mode B calls a REST service; Mode A runs the identical engine compiled to WebAssembly, locally, with no network call. This toggle forces Mode A so you can confirm decisions do not depend on a reachable server.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 19 | Tick 'Simulate outage'. Leave the dropdown beside it on retail_strict. Re-run 'Approve UNLIMITED WETH spend'. | Simulate outage: on. Outage profile: retail_strict. | The same NORMALIZE decision and the same amount options, evaluated entirely in your browser. No server round trip is involved in the decision. |
| 20 | Change the outage dropdown to institutional_strict and re-run. | Outage profile: institutional_strict. | BLOCK, with no decode attempted — FAIL_CLOSED. That profile chooses security over availability when the service is unreachable. Untick 'Simulate outage' before continuing. |
Switch to the Price Impact tab. Read the “Why price-impact protection matters” panel first — frequency (everyday thin pools, documented MEV/sandwich volume, catastrophic single-trade failures) is the product justification; the calculator below is the technical proof. Every result uses live Uniswap V2 USDC/WETH reserves via a read-only eth_call — no wallet, no gas. Exact percentages drift as the pool moves; judge the decision band, not a fixed digit.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 21 | Profile: Retail — Strict. Direction USDC → WETH. Use preset 1,000 (or type 1000). Calculate. | Amount: 1000 | ALLOW, price impact well under 1%. Rule AMM_SWAP_DETECTED. Plain-English panel states TINL would let a small trade through. Profile thresholds shown (Retail WARN/BLOCK %). |
| 22 | Change the amount to a mid-size trade (preset 500,000). Calculate. | Amount: 500000 | WARN, price impact on the order of several percent. Rule AMM_PRICE_IMPACT_WARN. Retail — Strict warns above 3%. Plain English explains the user would be paused before signing. |
| 23 | Use a large trade (preset 2,000,000). Calculate under Retail — Strict, then switch profile to Active DeFi User — Balanced and re-run the same amount. | Amount: 2000000 | Retail — Strict: BLOCK (AMM_PRICE_IMPACT_BLOCK, threshold 10%). Active DeFi User — Balanced: same impact may only WARN (higher threshold). Same trade, same pool, different posture — that is the policy claim. |
Every decision above — including the ones you cancelled — is written to an HMAC-chained audit log scoped to your organisation. Tamper-evidence is the property being demonstrated, not merely that a log exists.
| # | Do this | Input | Expected output |
|---|---|---|---|
| 24 | Scroll to 'Live Audit Log' on the Wallet Demo tab and click the refresh icon. | None. | The decisions you produced appear in order, each with its rule id and decision. Cancelled requests are present too — a refusal is a decision worth recording. |
| 25 | Check the chain verification indicator. | None. | Chain reports valid. Each entry commits to the one before it, so a silent edit would break verification. |
Record the result
| Date / evaluator | |
| Browser and wallet versions | |
| Step 7 — MetaMask showed the cap you typed | |
| Step 9 — BLOCK never opened a wallet prompt | |
| Steps 16–18 — Solana path (or marked skipped) | |
| Step 25 — audit chain reported valid | |
| Were you ever asked for a private key? |
Any failure at step 7 or step 9 is a release blocker for the Chrome / portal path. Completing this guide does not complete Mobile UAT (Android), and vice versa. Wording problems in the scope notes are honesty defects and should be fixed before further evaluators read them, even though they are not functional bugs.