// TINL · AUTHORIZATION_SAFETY · BEHIND_AN_EXISTING_BUTTON
A Button Should Do What It Says. TINL Checks That Before Anyone Approves It.
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.
// OUTSIDE_YOUR_AUDIENCE
The rest of this page is the TINL ecosystem detail — the product rules, a worked authorization example, the host contract, and where the layer may and may not sit inside an existing platform. Your selected audience does not lead with it, so it is collapsed rather than shown in full.