// TINL · AUTHORIZATION_SAFETY · BEHIND_AN_EXISTING_BUTTON
TINL — the Transaction Intent Normalization Layer — converts a technical permission into a clear statement of what it will do. It sits behind an action somebody is already taking: a wallet signature, an account connection, a digital-item approval, a game permission. The person keeps the screen, the account and the confirmation they already had.
Does this request do what the person believes it does, within safe limits?
That is the only question TINL answers, and it answers it before anything irreversible happens. It does not judge whether a game, a wallet or a platform is good or bad.
A green traffic light.
This request matches the action that was chosen and does not ask for unexpected power.
The normal confirmation continues exactly as before. ALLOW does not mean TINL signed anything on anyone's behalf, and it is not a promise that the request is safe forever.
A yellow traffic light.
This may be legitimate, but it grants a permission worth understanding before continuing.
The existing review screen explains the amount, the recipient and the end date. The point is not to frighten anyone — it is to turn a consequence into a sentence a person can decide with.
A red traffic light.
Do not continue. The request is unsafe, cannot be verified, or is not what was asked for.
The product's normal error screen appears and nothing reaches the signer. There is no continue-anyway button on a true block: one would only need an attacker to pressure someone into pressing it.
Correcting a form before it is submitted.
The request asks for more power than it needs, and a safer, smaller version is possible.
The original is discarded, not silently rewritten. A new, limited request is put in front of the person as its own action, so what they approved is a one-time bounded permission and the record says so.
Not a cryptocurrency, exchange, marketplace, token, or payment system. Not a new destination a player visits. It does not replace platform payments, a store's purchase flow, or a wallet's own confirmation screen.
// WHAT_IS_ENFORCED
BLOCK is the enforcement claim: where TINL's wrap is on the path, a blocked request never reaches the wallet. WARN and NORMALIZE are advisory as a whole against a hostile page — the page-forged proceed path was closed in August 2026, but digest-bind and MAIN-world wrap races remain — so the wallet's own confirmation stays the backstop for those two. No interception percentage is claimed.
// WHAT_SHIPS_TODAY
What ships today is a Chrome MV3 extension ready for independent UAT against MetaMask and Phantom, and an Android in-wallet Mode B demo on the WalletConnect path. The platform placements further down are an integration model, not live partners.
// WHAT_IT_DOES_NOT_DO
It does not prevent all phishing, discover every malicious website, detect all device compromise, reverse completed transfers, or guarantee reimbursement.
// WHERE_TINL_SITS
Audit firms, contest platforms, bounties and CI scanners all answer is the code I am about to deploy safe? They work on your repository, around launch, for the team that ships. a3e9 answers a question none of them does — should my desk touch this contract, right now, at the moment I connect and sign, and has something I already trusted changed underneath me? TINL is the part of that answer which reads the transaction before it is signed.
Transaction Intent Normalization Layer
Decodes what a transaction or signature actually does before it is signed, and applies policy to the decoded intent.
Execution-path assurance
Evaluates contract execution paths and issues verdicts, with decision memory and revalidation.
Governance Sentry
Watches pre-proposal state through destination-chain execution to catch capture inside the timelock window.
Oracle Governor
Owns the inputs — what each source may establish, how fresh, how independent, and what happens when it goes dark.
The evidence chain
The append-only record every verdict, correction and expiry is written to.
// WHAT_TINL_IS · WHAT_IT_IS_NOT
What does TINL mean?
Transaction Intent Normalization Layer. It converts a technical permission into a clear statement of what it will do.
The layer receives what somebody said they were doing, the authorization actually being proposed, and enough verified context to judge the two against each other. It returns one of four decisions to the host, and the host renders that decision in its own design language. Nothing about the product requires a person to learn the word TINL in order to use the thing it is protecting.
Does using it make a game “a crypto game”?
No. A game can use TINL to check its own account connections and permission requests with no token, marketplace, or cryptocurrency anywhere in the build. The Steam-shaped version of this product has no chain in it at all.
// NON_NEGOTIABLE_PRODUCT_RULES
Game first; security quiet by default.
A normal player should never need a wallet tutorial or a crypto vocabulary to play.
No payment bypass.
Platform payment and entitlement rules stay intact. Where a store requires its own in-app purchase path for in-app functionality, TINL does not offer an alternative one.
No hidden safety claim.
TINL must say what it checked, what it could not check, and why it reached the decision it reached. A silent pass is not a safety result.
Bytes before branding.
A familiar name, logo or page cannot make a request safe. The requested effect, target, scope and expiry are what get evaluated.
Least privilege.
A finite, time-limited permission for a known purpose is safer than unlimited, permanent authority — and NORMALIZE exists to offer the first in place of the second.
Fail closed for high-consequence uncertainty.
If a request cannot be decoded, verified, bounded, or matched to the selected action, the system does not quietly let it through.
App Attest, policy and wallet keys stay separate trust roles.
App integrity, policy authorization and user signing are three different powers. No single component should hold all three.
Treat minors and vulnerable users conservatively.
Do not introduce trading, cash-out, or financially consequential flows into child-oriented experiences. Hard blocks in a conservative profile are not silently disableable.
// WORKED_EXAMPLE · DECLARED_INTENT_MISMATCH
A community message says a limited tournament skin expires when the timer runs out. The link opens a page that copies the tournament's visual identity and asks for a wallet connection and one approval. The player believes they are claiming one cosmetic item. The request is an unlimited, never-expiring approval to an unfamiliar party.
Read this as an example, not a result. This is a worked example for a testnet or controlled environment. It is not a guarantee that every phishing campaign is detected.
| # | What happens | What TINL checks | Result |
|---|---|---|---|
| 1 | The player presses the existing “Claim reward” button. | The declared action is recorded: claim one event item. | There is now a baseline for what the person expects. |
| 2 | The integration hands the proposed authorization to TINL before the signer sees it. | Exact request bytes, account, chain, origin and session context. | Nothing has been signed or broadcast. |
| 3 | TINL decodes the real effect. | This is a permission grant, not a claim — with a spender, an amount and an expiry. | The request's machine meaning is visible in words. |
| 4 | TINL compares the declared action with the decoded effect. | A reward claim should not create a broad spending permission. | Declared-intent mismatch. |
| 5 | TINL checks the target and context. | Expected event manifest, code identity, origin and state snapshot. | The spender is not a verified event service — target unverified. |
| 6 | TINL applies the hard limits. | Permission breadth and lifetime: the amount is unlimited and the expiry absent. | Unbounded authority. |
| 7 | TINL returns BLOCK with reasons, not a generic error. | Reason codes travel with the decision so the host can explain it. | The signing adapter receives no candidate request at all. |
| 8 | The host renders its own normal safety language. | No blockchain lecture — the product's existing error component. | No approval occurs. |
| 9 | A privacy-minimized decision record is written locally. | Request hash, policy version, reason codes, time. Never a seed phrase or a key. | Support and incident review have evidence. |
| 10 | Optionally, and only with consent, a pseudonymous indicator is shared. | The malicious target fingerprint alone. | Threat context can improve without exposing anyone's secrets. |
TINL evaluates the request and the context handed to it. It cannot by itself know that a Discord impersonator sent the link, that a phishing email was written, or that a look-alike domain was registered — those need browser, email, community-moderation and threat-intelligence owners. Its narrower contribution is that even when somebody reaches the fraudulent page, a request obviously broader than the claimed action can be stopped before it is approved.
// SAFETY_API · A_SMALL_SERVICE
One safety brain, many compatible surfaces. A new host translates its ordinary action into this shared record and keeps its own confirmation, account, branding and payments.
TINL is offered as a repeatable service placed at an authorization point, not as a new consumer application. The host keeps its UI, its account system, its payments, its support and the final decision; it sends the shared record below and acts on one answer.
Declared action
What the person said they were doing — “claim one event item”.
Without it there is nothing to compare the real effect against.
Proposed effect
The transfer, approval, operator grant, account connection or session permission.
The actual action is evaluated, never the marketing label on the button.
Scope
Asset or item, amount, recipients, permissions, expiry, and any future authority.
This is what detects an unbounded grant — the shape of almost every drainer approval.
State context
Current allowance, nonce, code hash, policy version, and any known prior permission.
Without it a decision can be stale or inconsistent with what the account already granted.
Trust context
Verified service identity, code or contract identity, origin and session binding.
This is what catches look-alikes and wrong targets.
Policy profile
Which rule set applies in this context.
One engine, different boundaries per context, chosen by the host rather than the page.
Decision receipt
The decision, its reason codes, and a privacy-minimized record of what was checked.
A decision nobody can review afterwards is not evidence of anything.
// INTENDED_HOST_CONTRACT · NOT_THE_API_RUNNING_TODAY
This is the intended host contract, not the evaluator API running today. The TINL evaluator endpoints take a raw request and a profile; they have no declared-intent field, and the comparison below is the model this page is describing rather than a call anyone can make right now.
What the host would send — model, not a live call
{
"declared_action": "claim_one_event_item",
"origin_context": {
"source": "community_link",
"expected_event_id": "tournament-2026-spring"
},
"proposed_request": {
"kind": "token_approval",
"asset": "PocTestUSD",
"spender": "unknown-service",
"amount": "unlimited",
"expiry": "none"
}
}What the layer would answer — model, not a live call
{
"decision": "BLOCK",
"player_message": "This does not claim your event item. It would give an unverified service broad access.",
"reason_codes": [
"DECLARED_INTENT_MISMATCH",
"SPENDER_UNVERIFIED",
"APPROVAL_UNLIMITED",
"EXPIRY_UNBOUNDED"
],
"signing_candidate": null
}The policy engine that ships today has three profiles — retail_strict, trader_balanced and dev_passthrough. A child-safe profile is part of the model in the playbook and exists in no running engine; it is on the model side of the table below for that reason.
// PLACEMENT_RECOMMENDATION · WHAT_MUST_NOT_CHANGE
The best early integration is not a system-wide Apple, Steam, Xbox, or Play feature. It is a small integration inside one game, one embedded wallet, or one wallet-connection path that proves the safety model without changing platform payments or account rules.
Every store, console and XR row below is a boundary: what this product must not change inside rules those platforms publish for everyone. None of them is a customer, a partner or a live integration, no conversation with any of them is claimed here, and nothing on this page should be read as one. Only the wallet-connection placement is exercised today.
| Platform | Where TINL sits | What the player keeps | What TINL must not change |
|---|---|---|---|
Wallet or connection provider Live · UATThe Chrome MV3 extension is ready for independent UAT on this placement. The Android in-wallet Mode B demo sits on the same placement and is still building. | Directly before the sign/approve confirmation the wallet already shows. | The wallet's familiar confirmation screen, and the final say on it. | User control and wallet-local confirmation. TINL never auto-signs and is never handed a private key. |
Game account service Model | Before an external account link, a creator-event permission, or another high-consequence request the game's own service issues. | The game's UI, its account, and its own error and review components. | The studio's account model and its payments. TINL returns a decision; the game renders it in its existing design language. |
Apple / iPhone game Model | Inside the game's own account or optional external-permission service — outside StoreKit, never in front of it. | App Store purchase, Face ID confirmation, Game Center, and the existing screens. | Apple in-app purchase for in-app game functionality. A crypto wallet cannot unlock in-app benefits, and an optional external connection must never be the key that does. There is no system-wide Apple hook for this, and it must never be described as available. |
Steam / PC distributor Model | Publisher-side, on an ordinary account or community permission flow — or as a non-blockchain, synthetic safety-training module. | Steam login, the library, Steam Wallet, achievements, and normal game menus. | Steam's blockchain and NFT publication rule, and Steam commerce. A Steam build must contain no wallet connection, chain RPC, token, NFT path or external signing route, and no Steam credential leaves Steam's own mechanisms. Steam is not a wallet or blockchain pilot. |
Google Play / Android Model | App-side or wallet-side, on a confirmation the host already shows — using Android app-integrity signals only where the host already has them. | The Google account, the Play purchase flow, and the existing game UI. | Play billing and Play's tokenized-asset and blockchain-content rules. This is never an alternate commerce path. The Android build that ships today is an in-wallet WalletConnect demo, not a Play integration — the demo does not make this row live. |
Xbox / console Model | A game-service permission check before a high-consequence action the title already owns. | Xbox identity, parental controls, Store purchase, achievements, and the console UI. | Microsoft and Xbox commerce and account-control rules. This is not a system-wide Xbox feature and Xbox is not a customer. |
Meta / Quest Model | An app account or permission layer, or an XR safety experience the title already owns. | The Meta account, headset prompts, and the Horizon payment flow. | Meta's payment, anti-fraud and real-world-value restrictions. |
Placement patterns, not live surfaces: browser wallet connection, mobile or embedded wallet, game account service, an Apple-compatible optional-permission service, a Steam-compatible non-blockchain safety module, and a console game service. Only the browser wallet connection is live today; the mobile or embedded wallet path is building. The other four are patterns this page describes and nothing more.
// LIVE_TODAY · VERSUS · THE_INTEGRATION_MODEL
Live today — an evaluator can run this
Model, not shipping — none of this exists yet
Everything in the right-hand column is the integration model this page describes. None of it ships, none of it is scheduled here, and it is separated from the left-hand column precisely so the two cannot be read as one list.
// EXPLICIT_NON_CLAIMS
These stay non-claims however much of the roadmap is delivered. They are here because the defensible claim is narrower and more useful than any of them:
Deployed at a protected authorization boundary, TINL makes the exact requested action understandable, checks it against explicit policy and verified context, prevents defined unsafe requests from reaching execution, and creates evidence the host ecosystem can use.
This page describes an evaluation stage: a UAT-ready extension, a building mobile demo, and a model for where the layer sits. It is not a production or procurement claim.
// READ_NEXT
The implemented browser surface: the attack patterns it has rules for, the plain-language limits, and the roadmap that closes the remaining gaps.
Where TINL sits among Pathfinder, Governance Sentry, the Oracle Governor and the ledger — with the incidents that are covered, and the ones that are not.
The full browser acceptance test, ungated, with the expected decision at every step. Reading it needs no token.
The in-wallet acceptance test for the Mode B demo, ungated, with that build's limits stated in it.
One product, two surfaces: the Chrome extension and the Android in-wallet path, evaluated by the same policy engine. BLOCK versus advisory WARN/NORMALIZE is stated, Price Impact is described as a rule surface rather than a fourth product, and the two tracks are kept separate.
Assets, trust boundaries and attacker vectors for the wallet-security path, with the decision-strength table as the load-bearing part: BLOCK is enforced, WARN and NORMALIZE are advisory against a hostile page, and the wallet UI remains the backstop. No interception percentage is claimed — script ordering leaves some connections unwrapped, and TINL never sees those.
// WHO_IT_IS_FOR
Player
Direct“It makes sure a button does what it says before I agree to it.”
Parent
Companion“It helps stop a child from accidentally giving a stranger broad access through a confusing approval.”
Game studio
Direct“It protects high-consequence player actions without redesigning the game or turning us into a payments company.”
Wallet provider
Direct“It makes the confirmation we already show say what the exact request really does before it is signed.”
Apple
Boundary“An optional safety check around external permissions. StoreKit and in-app entitlements stay exactly where they are.”
Steam
Boundary“Safer digital permissions taught and enforced without being a blockchain, wallet or token product.”
TINL is a direct control only where it can act at the authorization moment — it needs the declared action, the actual proposed permission, and enough verified context to permit, explain, block or narrow that exact request. It is a companion control where somebody else owns the moment and has to enforce the answer. And it is not the answer at all to a problem that happens entirely before or after authorization: a phishing email, device malware, account takeover, asset recovery and payment refunds each have a different owner and a different system.
Audience: Wallet / intent security (TINL)
Current evaluation capability
Three surfaces, at three different stages. Only one row of this table describes a decision that cannot be ignored by the page it is protecting against.
| Surface | Status | BLOCK | WARN | NORMALIZE |
|---|---|---|---|---|
| chrome_mv32026.08 | UAT | HardInterceptThe request is not passed to the signer. | AdvisoryOnlyThe host is told. A hostile page can ignore the answer. | AdvisoryOnlyThe host is told. A hostile page can ignore the answer. |
| android_mode_b2026.08 | BUILDING | UnavailableNot available on this surface. | UnavailableNot available on this surface. | UnavailableNot available on this surface. |
| evaluator_web2026.08 | UAT | EvaluatorOnlyObserved on A3E9's own surface. Not evidence about a third-party wallet. | EvaluatorOnlyObserved on A3E9's own surface. Not evidence about a third-party wallet. | EvaluatorOnlyObserved on A3E9's own surface. Not evidence about a third-party wallet. |
Claim status legend
Decision states
Missing, stale or out-of-scope evidence is not a clean result. Today it produces the same decision as a clean one, which is reported below rather than smoothed over.
ALLOW lets the host continue its ordinary flow. WARN explains a specific risk. BLOCK stops the request reaching the signer. NORMALIZE discards the original and builds a bounded replacement the user approves separately.
Limitations
ALLOW means no rule in the active profile fired against what TINL could decode. It is not a statement that a transaction is safe, that a counterparty is honest, or that an outcome is guaranteed.
Limitations
A curated testnet example: a request granting unlimited spending approval is decoded, the profile returns NORMALIZE, and the payload is rebuilt with a bounded amount the evaluator chooses before anything reaches the wallet.
Draft target schema. It is not the public API running today and it does not authorize a production transaction.
Limitations
A proposed contract in which a host states what it believes it is asking for, alongside a commitment to the request it built, so the two can be compared before signing.
Draft target schema. It is not the public API running today and it does not authorize a production transaction.
Limitations
Coverage
Two different problems, measured separately because they have very different answers. Catching a permission you did not mean to grant is close to complete. Pricing the route a trade takes is not.
Authorization — a hostile or compromised site obtaining a signed permission
measured: 12829/12840 (99.91%) of authorization transactions decoded to a specific intent
Decoded and assessed
Detected but not assessed
Where one of these is still decoded as a swap — a multi-hop path, or a venue whose pool cannot be resolved — it reaches the baseline swap rule, which every shipped profile allows, and the decision is indistinguishable from one that was assessed and found acceptable. Where it is not recognised as a swap at all, it reaches the unknown-selector rule and warns instead.
Routing — an honest site sending a trade through a thin or wrong pool
measured: 28/1070 (2.6%) of transactions bound for a known DEX router are priceable
Decoded and assessed
Detected but not assessed
Where one of these is still decoded as a swap — a multi-hop path, or a venue whose pool cannot be resolved — it reaches the baseline swap rule, which every shipped profile allows, and the decision is indistinguishable from one that was assessed and found acceptable. Where it is not recognised as a swap at all, it reaches the unknown-selector rule and warns instead.
Routing — an honest site sending a trade through a thin or wrong pool
measured: 34/944 (3.6%) of transactions bound for a known DEX router are priceable
Decoded and assessed
Detected but not assessed
Where one of these is still decoded as a swap — a multi-hop path, or a venue whose pool cannot be resolved — it reaches the baseline swap rule, which every shipped profile allows, and the decision is indistinguishable from one that was assessed and found acceptable. Where it is not recognised as a swap at all, it reaches the unknown-selector rule and warns instead.
Routing — an honest site sending a trade through a thin or wrong pool
measured: 1602/3632 (44.1%) of transactions bound for a known DEX router are priceable
Decoded and assessed
Detected but not assessed
Where one of these is still decoded as a swap — a multi-hop path, or a venue whose pool cannot be resolved — it reaches the baseline swap rule, which every shipped profile allows, and the decision is indistinguishable from one that was assessed and found acceptable. Where it is not recognised as a swap at all, it reaches the unknown-selector rule and warns instead.
Non-claims
TINL does not prevent phishing in general, does not detect a compromised device, cannot reverse a transfer once it is on chain, guarantees no reimbursement, does not bypass a payment rail, and does not replace a wallet. It does not enforce universally: on some surfaces its answer is advice a hostile page can ignore.
Limitations
TINL never receives a private key, a seed phrase or a recovery phrase, and holds no authority to move value. It reads a request and returns a decision. Signing stays with the wallet the user already controls.
Limitations
Evaluator access
Approved scenarios on testnets, using wallets the evaluator controls, plus a read-only mainnet reserve read. Unredacted production pre-sign intent is rejected before the evaluator is invoked.
Limitations
Access is by invitation and limited to the stated UAT scope. Submitting a request records an intent to evaluate; it does not create an account, a session or a download.
Limitations