A3E9 logoA3E9
// AUDIENCE_FILTERShowing content for Wallet / intent security (TINL). De-emphasized: The HSM vendor matrix and KeySync ledger internals.
Showing the Wallet / intent security (TINL) view.

// 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.

ALLOW

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.

WARN

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.

BLOCK

A red traffic light.

Stopped, because the person set TINL to stop requests like this one, or because TINL cannot run safely on the device. TINL never stops a request on its own judgment of what someone should do; a request it could not check is a warning, not a stop.

Nothing reaches the signer, and TINL's window says which recorded setting stopped it and where to change it. There is no continue-anyway button: to undo a stop the person changes that setting, and the change is recorded.

NORMALIZE

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. 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.

Wallet Scams — what shipsSafe to Touch — the assurance line UAT procedure (Chrome) Published documents

// WHAT_TINL_CHECKS

What TINL checks, in plain words

Every check TINL runs on a wallet request, what it looks like, why it matters, and what each profile does about it. Choose a row to walk through it. The explanations are the words the extension itself shows you; the decisions are read from the profiles it ships.

Retail and trader profiles warn by default and stop nothing on their own. Turning on "stop instead of warning" makes every warning a block. The institutional profile blocks on an administrator's authority.

CheckCheck One check TINL runs on a wallet request, named in the words the extension shows you. Choose a row to walk through the request, why it matters, and what each profile does about it.Retail — StrictRetail — Strict For someone new to crypto, or anyone who wants every risky request explained. It is TINL's default. Warns with the reason before anything risky reaches your wallet, and offers a smaller permission when a site asks for more than it needs. It stops nothing on its own; turn on "stop instead of warning" and every warning becomes a stop. Of the 59 checks it allows 20, warns on 36, offers a smaller permission on 3 and blocks 0.Active trader — BalancedActive trader — Balanced For an active trader who understands the risks and signs often. Lets more routine trading requests through without a window than Retail does, and still warns before the risky ones. Like Retail, it stops nothing unless you turn on "stop instead of warning". Of the 59 checks it allows 26, warns on 31, offers a smaller permission on 2 and blocks 0.Institutional — StrictInstitutional — Strict For a firm, where an administrator sets the policy for the people who sign. Blocks what it does not recognise as safe, on the administrator's authority, rather than asking the person signing. Its stops are the organisation's recorded choice. Of the 59 checks it allows 18, warns on 11, offers a smaller permission on 0 and blocks 30.
Unlimited spending approvalUnlimited spending approval This grants another address standing permission to move tokens out of your wallet whenever it chooses — not a one-time transfer, an open-ended authorization with no cap and no expiry. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictNORMALIZEActive trader — BalancedNORMALIZEInstitutional — StrictBLOCK

Unlimited spending approval

This grants another address standing permission to move tokens out of your wallet whenever it chooses — not a one-time transfer, an open-ended authorization with no cap and no expiry.

ERC20_UNLIMITED_APPROVE

This gives a known drainer access to your assetsThis gives a known drainer access to your assets The address this request would let spend your tokens or move your NFTs is listed in your threat intelligence feed as one used by a wallet-draining operation. Once it has that permission, it can take those assets whenever it chooses, without asking you again. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

This gives a known drainer access to your assets

The address this request would let spend your tokens or move your NFTs is listed in your threat intelligence feed as one used by a wallet-draining operation. Once it has that permission, it can take those assets whenever it chooses, without asking you again.

COUNTERPARTY_KNOWN_DRAINER

Bounded spending approvalBounded spending approval This grants another address permission to move up to a specific, finite amount of tokens out of your wallet — the normal, legitimate shape of an approval, e.g. authorizing an exchange to swap a specific amount. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Bounded spending approval

This grants another address permission to move up to a specific, finite amount of tokens out of your wallet — the normal, legitimate shape of an approval, e.g. authorizing an exchange to swap a specific amount.

ERC20_BOUNDED_APPROVE

Approval for your entire NFT collectionApproval for your entire NFT collection This grants another address permission to transfer ANY token from this entire collection out of your wallet, not just one — one signature covers everything you hold or will ever hold from this contract. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Approval for your entire NFT collection

This grants another address permission to transfer ANY token from this entire collection out of your wallet, not just one — one signature covers everything you hold or will ever hold from this contract.

ERC721_SET_APPROVAL_ALL

Revoking collection-wide approvalRevoking collection-wide approval This removes a previously granted collection-wide transfer permission — the safe direction. Revoking access someone else already had is generally something to encourage, not flag. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Revoking collection-wide approval

This removes a previously granted collection-wide transfer permission — the safe direction. Revoking access someone else already had is generally something to encourage, not flag.

ERC721_REVOKE_APPROVAL_ALL

Unlimited spending approval, via signatureUnlimited spending approval, via signature EIP-2612 "permit" grants the exact same standing spending permission as an on-chain unlimited approval, but through a signed message instead of a transaction — no gas fee, which means it shows up constantly in ordinary DeFi flows and gets signed with far less scrutiny than a real transaction. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictNORMALIZEActive trader — BalancedWARNInstitutional — StrictBLOCK

Unlimited spending approval, via signature

EIP-2612 "permit" grants the exact same standing spending permission as an on-chain unlimited approval, but through a signed message instead of a transaction — no gas fee, which means it shows up constantly in ordinary DeFi flows and gets signed with far less scrutiny than a real transaction.

EIP2612_PERMIT_UNLIMITED

Bounded spending approval, via signatureBounded spending approval, via signature Same mechanism as an unlimited permit above, but for a specific, finite amount — the normal, legitimate use of a gasless approval. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Bounded spending approval, via signature

Same mechanism as an unlimited permit above, but for a specific, finite amount — the normal, legitimate use of a gasless approval.

EIP2612_PERMIT_BOUNDED

Signature-based approval that (practically) never expiresSignature-based approval that (practically) never expires This gasless approval's deadline is set so far in the future that it functions as permanent — most legitimate DeFi permits expire within minutes to hours. An approval that stays valid indefinitely can be used at any point later, long after you've forgotten you signed it, including if your wallet is ever compromised in the future. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Signature-based approval that (practically) never expires

This gasless approval's deadline is set so far in the future that it functions as permanent — most legitimate DeFi permits expire within minutes to hours. An approval that stays valid indefinitely can be used at any point later, long after you've forgotten you signed it, including if your wallet is ever compromised in the future.

EIP2612_PERMIT_DEADLINE_FAR_FUTURE

Unlimited spending approval (SPL)Unlimited spending approval (SPL) This delegates standing permission to move tokens out of this token account, for an amount at or near the maximum a token account can ever hold — the Solana equivalent of an unlimited ERC-20 approval, and the same drainer technique: sign once, and the delegate can empty this token account at any point later. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictNORMALIZEActive trader — BalancedNORMALIZEInstitutional — StrictBLOCK

Unlimited spending approval (SPL)

This delegates standing permission to move tokens out of this token account, for an amount at or near the maximum a token account can ever hold — the Solana equivalent of an unlimited ERC-20 approval, and the same drainer technique: sign once, and the delegate can empty this token account at any point later.

SPL_UNLIMITED_APPROVE

Bounded spending approval (SPL)Bounded spending approval (SPL) This delegates permission to move up to a specific, finite amount from this token account — the normal, legitimate shape of an SPL approval. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Bounded spending approval (SPL)

This delegates permission to move up to a specific, finite amount from this token account — the normal, legitimate shape of an SPL approval.

SPL_BOUNDED_APPROVE

Revoking a delegate (SPL)Revoking a delegate (SPL) This removes a previously granted delegate authority from this token account — the safe direction, generally something to encourage. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Revoking a delegate (SPL)

This removes a previously granted delegate authority from this token account — the safe direction, generally something to encourage.

SPL_REVOKE_APPROVAL

Hands control of a token account to someone elseHands control of a token account to someone else This changes who controls one of your token accounts (or a token mint). When the change is to the account's owner, the new owner can move everything in that account afterwards, without asking you again. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Hands control of a token account to someone else

This changes who controls one of your token accounts (or a token mint). When the change is to the account's owner, the new owner can move everything in that account afterwards, without asking you again.

SPL_SET_AUTHORITY

Hands your account to another programHands your account to another program This changes which program controls an account — if it is your wallet account, the SOL in it would then be controlled by that program's code instead of by your signature. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Hands your account to another program

This changes which program controls an account — if it is your wallet account, the SOL in it would then be controlled by that program's code instead of by your signature.

SOLANA_ACCOUNT_ASSIGN

Someone else would gain control of one of your accountsSomeone else would gain control of one of your accounts Running this transaction shows no money moving — and one of your accounts changing hands: a spending delegate, the account's owner, its close authority, or the program that controls it. Permissions you hand over: Approvals and authorities that let someone else move your assets later.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Someone else would gain control of one of your accounts

Running this transaction shows no money moving — and one of your accounts changing hands: a spending delegate, the account's owner, its close authority, or the program that controls it.

SOLANA_SIMULATED_AUTHORITY_CHANGE

Token transferToken transfer This moves tokens out of your wallet right now, for a specific amount — not a standing permission for later. You always know exactly what's leaving the moment you sign. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Token transfer

This moves tokens out of your wallet right now, for a specific amount — not a standing permission for later. You always know exactly what's leaving the moment you sign.

ERC20_TRANSFER

Token pull, from your own accountToken pull, from your own account This moves tokens right now, pulled from an account that matches your own wallet address — functionally the same as an ordinary transfer, just using a different function to do it. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Token pull, from your own account

This moves tokens right now, pulled from an account that matches your own wallet address — functionally the same as an ordinary transfer, just using a different function to do it.

ERC20_TRANSFER_FROM

Token pull from someone else's accountToken pull from someone else's account This moves tokens out of an account that is NOT your own wallet — you would be the one signing it, but the funds would come from somebody else's balance, using an allowance they previously granted. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Token pull from someone else's account

This moves tokens out of an account that is NOT your own wallet — you would be the one signing it, but the funds would come from somebody else's balance, using an allowance they previously granted.

ERC20_TRANSFER_FROM_THIRD_PARTY

Sending the chain's own coinSending the chain's own coin This sends the network's native coin (ETH on Ethereum, BNB on BNB Chain, and so on) directly to an address, with no contract call attached. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Sending the chain's own coin

This sends the network's native coin (ETH on Ethereum, BNB on BNB Chain, and so on) directly to an address, with no contract call attached.

EVM_NATIVE_TRANSFER

Token transfer (SPL)Token transfer (SPL) This moves tokens out of this token account right now, for a specific amount — not a standing delegation for later. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Token transfer (SPL)

This moves tokens out of this token account right now, for a specific amount — not a standing delegation for later.

SPL_TRANSFER

Sending SOLSending SOL This transfers SOL, Solana's own coin, from your account to another address using the System Program — no token program and no contract call involved. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Sending SOL

This transfers SOL, Solana's own coin, from your account to another address using the System Program — no token program and no contract call involved.

SOLANA_NATIVE_TRANSFER

This sends nearly all of something you ownThis sends nearly all of something you own This request would move almost your entire balance of an asset out of your wallet in one go. That is sometimes exactly what you mean — moving everything to an exchange or a new wallet — but it is also exactly what a drain looks like. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictWARN

This sends nearly all of something you own

This request would move almost your entire balance of an asset out of your wallet in one go. That is sometimes exactly what you mean — moving everything to an exchange or a new wallet — but it is also exactly what a drain looks like.

BALANCE_SWEEP

This empties several of your assets at onceThis empties several of your assets at once This single request would move nearly all of two or more different assets out of your wallet. Moving everything to one new place is rare in normal use; emptying several balances in one signature is how wallet drains are built. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

This empties several of your assets at once

This single request would move nearly all of two or more different assets out of your wallet. Moving everything to one new place is rare in normal use; emptying several balances in one signature is how wallet drains are built.

BALANCE_SWEEP_MULTI_ASSET

Spend exceeds your configured limitSpend exceeds your configured limit This is a bounded, finite approval or transfer — but its real-world USD value (resolved via a live price oracle) is higher than the spending cap your active profile allows for a single request. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Spend exceeds your configured limit

This is a bounded, finite approval or transfer — but its real-world USD value (resolved via a live price oracle) is higher than the spending cap your active profile allows for a single request.

SPENDING_CAP_EXCEEDED

Sends money into a function TINL can't identifySends money into a function TINL can't identify This calls a contract function TINL doesn't recognize, and it also sends native currency (ETH or the chain's equivalent) along with the call. Whatever that function does with the money, you can't get it back by cancelling afterwards. Money leaving now: Transfers, and requests that would take most of what you hold.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Sends money into a function TINL can't identify

This calls a contract function TINL doesn't recognize, and it also sends native currency (ETH or the chain's equivalent) along with the call. Whatever that function does with the money, you can't get it back by cancelling afterwards.

SELECTOR_UNKNOWN_WITH_VALUE

Message signedMessage signed This signs a plain, human-readable message — not a transaction, and not something that moves tokens or grants a permission on its own. Common for logging into a website or proving you control this wallet. Signatures and log-ins: Messages and sign-in requests, including ones that are not what they say.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Message signed

This signs a plain, human-readable message — not a transaction, and not something that moves tokens or grants a permission on its own. Common for logging into a website or proving you control this wallet.

EVM_MESSAGE_SIGNED

Non-text messageNon-text message You're being asked to sign data that isn't readable text, so neither you nor TINL can see what it says. Some apps do use raw-byte login challenges, but you can't confirm what you're agreeing to the way you normally could. Signatures and log-ins: Messages and sign-in requests, including ones that are not what they say.Retail — StrictWARNActive trader — BalancedALLOWInstitutional — StrictWARN

Non-text message

You're being asked to sign data that isn't readable text, so neither you nor TINL can see what it says. Some apps do use raw-byte login challenges, but you can't confirm what you're agreeing to the way you normally could.

EVM_MESSAGE_NON_UTF8

Signing a hash you can't readSigning a hash you can't read This asks you to sign a 32-byte fingerprint of something else — not words, not a transaction you can review. Some contracts accept a signature like this as your consent to an order, a listing or a transfer, so what you are really approving is whatever that fingerprint stands for. Signatures and log-ins: Messages and sign-in requests, including ones that are not what they say.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Signing a hash you can't read

This asks you to sign a 32-byte fingerprint of something else — not words, not a transaction you can review. Some contracts accept a signature like this as your consent to an order, a listing or a transfer, so what you are really approving is whatever that fingerprint stands for.

EVM_MESSAGE_BLIND_HASH

Message signedMessage signed This signs a plain, human-readable message — not a transaction, and not something that moves tokens or grants any permission on its own. Common for logging into a website ('Sign In With Solana') or proving you control this wallet. Signatures and log-ins: Messages and sign-in requests, including ones that are not what they say.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Message signed

This signs a plain, human-readable message — not a transaction, and not something that moves tokens or grants any permission on its own. Common for logging into a website ('Sign In With Solana') or proving you control this wallet.

SOLANA_MESSAGE_SIGNED

Non-text messageNon-text message You're being asked to sign a message that isn't ordinary readable text — it's raw data TINL can't display as words. Some legitimate apps do use raw-byte challenges for logging in, but it's unusual, and you can't visually confirm what you're actually signing the way you normally could. Signatures and log-ins: Messages and sign-in requests, including ones that are not what they say.Retail — StrictWARNActive trader — BalancedALLOWInstitutional — StrictWARN

Non-text message

You're being asked to sign a message that isn't ordinary readable text — it's raw data TINL can't display as words. Some legitimate apps do use raw-byte challenges for logging in, but it's unusual, and you can't visually confirm what you're actually signing the way you normally could.

SOLANA_MESSAGE_NON_UTF8

This 'message' is actually a transaction in disguiseThis 'message' is actually a transaction in disguise You were asked to sign a plain message — but the data underneath is actually a real, fully-formed transaction, not text. This is a real phishing technique: a site asks your wallet to 'just sign a message' (which normally feels lower-stakes and skips your wallet's transaction-review screen), then submits your signature on-chain as if you'd approved a real transaction. Signatures and log-ins: Messages and sign-in requests, including ones that are not what they say.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

This 'message' is actually a transaction in disguise

You were asked to sign a plain message — but the data underneath is actually a real, fully-formed transaction, not text. This is a real phishing technique: a site asks your wallet to 'just sign a message' (which normally feels lower-stakes and skips your wallet's transaction-review screen), then submits your signature on-chain as if you'd approved a real transaction.

SOLANA_MESSAGE_LOOKS_LIKE_TRANSACTION

Unrecognized signature requestUnrecognized signature request This is a structured (EIP-712) signature request that doesn't match the EIP-2612 permit schema TINL knows how to interpret. It could authorize almost anything — TINL can't say more about what it actually does. Signatures and log-ins: Messages and sign-in requests, including ones that are not what they say.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Unrecognized signature request

This is a structured (EIP-712) signature request that doesn't match the EIP-2612 permit schema TINL knows how to interpret. It could authorize almost anything — TINL can't say more about what it actually does.

UNRECOGNIZED_TYPED_DATA

This login is for a different websiteThis login is for a different website You're being asked to sign a "Sign in with..." message for one website, but the page asking is a different website. A login signature is proof you control this wallet; a lookalike page collecting one for the real site can use it there as you. Signatures and log-ins: Messages and sign-in requests, including ones that are not what they say.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

This login is for a different website

You're being asked to sign a "Sign in with..." message for one website, but the page asking is a different website. A login signature is proof you control this wallet; a lookalike page collecting one for the real site can use it there as you.

SIGN_IN_DOMAIN_MISMATCH

This site is imitating another oneThis site is imitating another one The website asking for this signature is not the site it looks like. Its address is built to pass for a well-known wallet or app — letters swapped for look-alikes, a one-letter typo, or the real address hidden inside a longer one. The site, and what it did before: Look-alike sites, and a second request that differs from the first.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

This site is imitating another one

The website asking for this signature is not the site it looks like. Its address is built to pass for a well-known wallet or app — letters swapped for look-alikes, a one-letter typo, or the real address hidden inside a longer one.

SITE_LOOKALIKE_DOMAIN

This site uses a well-known name, but it is not that project's siteThis site uses a well-known name, but it is not that project's site The website's address contains the name of a well-known wallet or app, but it is not that project's official domain. It may be a fan site, an unrelated project — or an imitation. The site, and what it did before: Look-alike sites, and a second request that differs from the first.Retail — StrictWARNActive trader — BalancedALLOWInstitutional — StrictWARN

This site uses a well-known name, but it is not that project's site

The website's address contains the name of a well-known wallet or app, but it is not that project's official domain. It may be a fan site, an unrelated project — or an imitation.

SITE_BRAND_IN_UNKNOWN_DOMAIN

Asked to sign the moment you connectedAsked to sign the moment you connected You connected your wallet to this site seconds ago, and it is already asking you to sign a transaction or an approval. You have not used this site before. The site, and what it did before: Look-alike sites, and a second request that differs from the first.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictWARN

Asked to sign the moment you connected

You connected your wallet to this site seconds ago, and it is already asking you to sign a transaction or an approval. You have not used this site before.

SESSION_CONNECT_THEN_SIGN

A new site, paying an address you have never usedA new site, paying an address you have never used You have not used this site before, and this request sends value to an address you have never sent to anywhere. Neither is wrong on its own; together they are worth a second look at the address. The site, and what it did before: Look-alike sites, and a second request that differs from the first.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictWARN

A new site, paying an address you have never used

You have not used this site before, and this request sends value to an address you have never sent to anywhere. Neither is wrong on its own; together they are worth a second look at the address.

SESSION_NEW_SITE_NEW_COUNTERPARTY

This is not what you did on this site a moment agoThis is not what you did on this site a moment ago Earlier on this same site you approved something else. This request pays a different address, or moves assets you did not move before, than anything you let through here in the last half hour. The site, and what it did before: Look-alike sites, and a second request that differs from the first.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

This is not what you did on this site a moment ago

Earlier on this same site you approved something else. This request pays a different address, or moves assets you did not move before, than anything you let through here in the last half hour.

SESSION_INTENT_DEVIATION

A second request on this site is trying to empty your walletA second request on this site is trying to empty your wallet After what you already approved on this site, this new request would move nearly all of an asset — to an address or in a way you did not use here before. The site, and what it did before: Look-alike sites, and a second request that differs from the first.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

A second request on this site is trying to empty your wallet

After what you already approved on this site, this new request would move nearly all of an asset — to an address or in a way you did not use here before.

SESSION_DEVIATION_WITH_SWEEP

This site has reached the limit you set for a new siteThis site has reached the limit you set for a new site You have not used this site before, and together with what you have already approved here, this request would move more of one of your balances than your limit for a new site allows. The site, and what it did before: Look-alike sites, and a second request that differs from the first.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

This site has reached the limit you set for a new site

You have not used this site before, and together with what you have already approved here, this request would move more of one of your balances than your limit for a new site allows.

SESSION_BUDGET_EXCEEDED

Unrecognized contract functionUnrecognized contract function This calls a contract function TINL doesn't recognize — not a standard ERC-20/721/1155 method, and not present in the open selector registry or the Threat Intel Tier. It might be a legitimate, less common contract TINL simply doesn't know about yet, or it might be a custom function chosen specifically because it doesn't look familiar to anyone reviewing it. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictWARNActive trader — BalancedALLOWInstitutional — StrictBLOCK

Unrecognized contract function

This calls a contract function TINL doesn't recognize — not a standard ERC-20/721/1155 method, and not present in the open selector registry or the Threat Intel Tier. It might be a legitimate, less common contract TINL simply doesn't know about yet, or it might be a custom function chosen specifically because it doesn't look familiar to anyone reviewing it.

SELECTOR_UNKNOWN

Recognized standard operationRecognized standard operation This calls a function TINL's registry recognizes by name (e.g. a common DeFi or token-standard operation), but doesn't have a dedicated risk-pattern decoder for — distinct from a fully unknown selector, since at least the operation itself is a known, named one. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Recognized standard operation

This calls a function TINL's registry recognizes by name (e.g. a common DeFi or token-standard operation), but doesn't have a dedicated risk-pattern decoder for — distinct from a fully unknown selector, since at least the operation itself is a known, named one.

SELECTOR_RECOGNIZED_STANDARD

Selector flagged by threat intelligenceSelector flagged by threat intelligence This calls a function specifically identified and listed in TINL's Threat Intelligence Tier — a known drainer selector or malicious permit variant someone has already identified in the wild, not merely an unfamiliar one. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Selector flagged by threat intelligence

This calls a function specifically identified and listed in TINL's Threat Intelligence Tier — a known drainer selector or malicious permit variant someone has already identified in the wild, not merely an unfamiliar one.

THREAT_INTEL_FLAGGED_SELECTOR

Unrecognized SPL Token instructionUnrecognized SPL Token instruction This transaction includes an SPL Token program instruction with a discriminant TINL doesn't recognize as approve, transfer, or revoke — TINL can't say what it actually does. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Unrecognized SPL Token instruction

This transaction includes an SPL Token program instruction with a discriminant TINL doesn't recognize as approve, transfer, or revoke — TINL can't say what it actually does.

SPL_UNKNOWN_INSTRUCTION

Account TINL couldn't resolveAccount TINL couldn't resolve This transaction references an account (via a Solana address-lookup table) that TINL wasn't able to resolve to a real address — rather than guess or skip it, TINL treats this as unreviewable and flags it, since evaluating the wrong account would be worse than not evaluating at all. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Account TINL couldn't resolve

This transaction references an account (via a Solana address-lookup table) that TINL wasn't able to resolve to a real address — rather than guess or skip it, TINL treats this as unreviewable and flags it, since evaluating the wrong account would be worse than not evaluating at all.

SPL_UNRESOLVABLE_ACCOUNT

No SPL Token instructions foundNo SPL Token instructions found This transaction doesn't contain any SPL Token program instruction TINL can decode — it might move SOL directly, call an entirely different program, or use an instruction shape TINL doesn't parse. This is TINL's own blind spot on Solana, flagged explicitly rather than silently allowed. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

No SPL Token instructions found

This transaction doesn't contain any SPL Token program instruction TINL can decode — it might move SOL directly, call an entirely different program, or use an instruction shape TINL doesn't parse. This is TINL's own blind spot on Solana, flagged explicitly rather than silently allowed.

SPL_NO_TOKEN_INSTRUCTIONS

Part of this transaction could not be readPart of this transaction could not be read TINL recognized some of what this transaction does, but it also contains an instruction for a program TINL cannot read. The part TINL could read may be harmless; the part it could not is the part that matters. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Part of this transaction could not be read

TINL recognized some of what this transaction does, but it also contains an instruction for a program TINL cannot read. The part TINL could read may be harmless; the part it could not is the part that matters.

SOLANA_UNRECOGNIZED_INSTRUCTION

Long-lived authorization (durable nonce)Long-lived authorization (durable nonce) This transaction uses a durable nonce instead of a normal, short-lived one — most Solana transactions expire on their own within a minute or two if not submitted, but this one doesn't. It can sit around and be submitted much later than you might expect. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Long-lived authorization (durable nonce)

This transaction uses a durable nonce instead of a normal, short-lived one — most Solana transactions expire on their own within a minute or two if not submitted, but this one doesn't. It can sit around and be submitted much later than you might expect.

SOLANA_DURABLE_NONCE_TRANSACTION

Couldn't read it — but nothing of yours would moveCouldn't read it — but nothing of yours would move TINL does not recognize the program this transaction calls. Running it against your own node shows none of your balances leaving and nothing of yours changing hands, so it is not treated as a refusal. What TINL cannot fully read: Functions and instructions nobody can decode, said plainly rather than passed as fine.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictWARN

Couldn't read it — but nothing of yours would move

TINL does not recognize the program this transaction calls. Running it against your own node shows none of your balances leaving and nothing of yours changing hands, so it is not treated as a refusal.

SOLANA_SIMULATED_NO_MOVEMENT

Transfer with a built-in feeTransfer with a built-in fee This token charges a small fee on every transfer, built into the token itself — the amount that actually arrives at the destination is a little less than the amount being sent, with the difference collected as a fee. What the token itself allows: Properties of a token that no transaction discloses.Retail — StrictWARNActive trader — BalancedALLOWInstitutional — StrictWARN

Transfer with a built-in fee

This token charges a small fee on every transfer, built into the token itself — the amount that actually arrives at the destination is a little less than the amount being sent, with the difference collected as a fee.

TOKEN2022_TRANSFER_FEE

Whoever issued this token can take it backWhoever issued this token can take it back This token was created with a permanent delegate: a fixed address that can transfer or burn it out of anyone's account at any time, without that person approving anything. It is set when the token is created and can never be removed. What the token itself allows: Properties of a token that no transaction discloses.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

Whoever issued this token can take it back

This token was created with a permanent delegate: a fixed address that can transfer or burn it out of anyone's account at any time, without that person approving anything. It is set when the token is created and can never be removed.

TOKEN2022_PERMANENT_DELEGATE

This token's issuer can freeze your accountThis token's issuer can freeze your account The token has a freeze authority — an address that can freeze holders' accounts, after which the balance cannot be moved or sold by the person who owns it. What the token itself allows: Properties of a token that no transaction discloses.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

This token's issuer can freeze your account

The token has a freeze authority — an address that can freeze holders' accounts, after which the balance cannot be moved or sold by the person who owns it.

SPL_MINT_FREEZE_AUTHORITY

A brand-new token whose creator kept control of itA brand-new token whose creator kept control of it One of the tokens in this transaction was created only days ago, and whoever created it can still make more of it, freeze your account holding it, or both. A new token is not wrong by itself: on a busy day more than 200,000 are created, and most launch with those powers already given up. What the token itself allows: Properties of a token that no transaction discloses.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictWARN

A brand-new token whose creator kept control of it

One of the tokens in this transaction was created only days ago, and whoever created it can still make more of it, freeze your account holding it, or both. A new token is not wrong by itself: on a busy day more than 200,000 are created, and most launch with those powers already given up.

SPL_MINT_NEWLY_CREATED

Token swap through a liquidity poolToken swap through a liquidity pool This calls a decentralized exchange function that swaps one token for another through an automated market maker (AMM) liquidity pool. Swaps and prices: How much of a pool a trade would consume, when the pool can be read.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Token swap through a liquidity pool

This calls a decentralized exchange function that swaps one token for another through an automated market maker (AMM) liquidity pool.

AMM_SWAP_DETECTED

Token swap through a concentrated-liquidity poolToken swap through a concentrated-liquidity pool This swaps one token for another through a concentrated-liquidity pool (Uniswap V3 and pools like it), where liquidity is placed in price ranges rather than spread across the whole curve. Swaps and prices: How much of a pool a trade would consume, when the pool can be read.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

Token swap through a concentrated-liquidity pool

This swaps one token for another through a concentrated-liquidity pool (Uniswap V3 and pools like it), where liquidity is placed in price ranges rather than spread across the whole curve.

AMM_V3_SWAP_DETECTED

A swap TINL could not priceA swap TINL could not price This is a token swap, but TINL could not read the pool it trades against, so it has no live reserve figure and cannot tell you what this trade would cost in price impact. Swaps and prices: How much of a pool a trade would consume, when the pool can be read.Retail — StrictWARNActive trader — BalancedALLOWInstitutional — StrictWARN

A swap TINL could not price

This is a token swap, but TINL could not read the pool it trades against, so it has no live reserve figure and cannot tell you what this trade would cost in price impact.

AMM_SWAP_UNPRICED

This trade would move an unusually large share of the poolThis trade would move an unusually large share of the pool TINL checked this swap against the target liquidity pool's real, live on-chain reserves. This trade would consume enough of the pool that you'd receive meaningfully less than the current market price — a sign the pool may be too shallow for a trade this size. Swaps and prices: How much of a pool a trade would consume, when the pool can be read.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictWARN

This trade would move an unusually large share of the pool

TINL checked this swap against the target liquidity pool's real, live on-chain reserves. This trade would consume enough of the pool that you'd receive meaningfully less than the current market price — a sign the pool may be too shallow for a trade this size.

AMM_PRICE_IMPACT_WARN

This trade would drain a large share of the poolThis trade would drain a large share of the pool TINL checked this swap against the target liquidity pool's real, live on-chain reserves. This trade is large enough relative to the pool that a very significant share of your value would be lost to price impact — not a hypothetical risk, a direct consequence of the pool's own reserve math. Swaps and prices: How much of a pool a trade would consume, when the pool can be read.Retail — StrictWARNActive trader — BalancedWARNInstitutional — StrictBLOCK

This trade would drain a large share of the pool

TINL checked this swap against the target liquidity pool's real, live on-chain reserves. This trade is large enough relative to the pool that a very significant share of your value would be lost to price impact — not a hypothetical risk, a direct consequence of the pool's own reserve math.

AMM_PRICE_IMPACT_BLOCK

A cheaper route existed for this swapA cheaper route existed for this swap TINL quoted this trade against other liquidity pools it could read at the same block, and at least one of them would have returned more of the token you are buying. Swaps and prices: How much of a pool a trade would consume, when the pool can be read.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

A cheaper route existed for this swap

TINL quoted this trade against other liquidity pools it could read at the same block, and at least one of them would have returned more of the token you are buying.

AMM_ROUTE_INFERIOR

How much better the best route wasHow much better the best route was The measured difference between what this trade returns and what the best route TINL could read would have returned, carried alongside the decision rather than acting as one. Swaps and prices: How much of a pool a trade would consume, when the pool can be read.Retail — StrictALLOWActive trader — BalancedALLOWInstitutional — StrictALLOW

How much better the best route was

The measured difference between what this trade returns and what the best route TINL could read would have returned, carried alongside the decision rather than acting as one.

AMM_ROUTE_EDGE

Decisions and explanations from TINL engine 2a204aa.

// YOUR_CHOICES · WHAT_IS_RECORDED

TINL warns. You decide. What you decide is recorded.

People sometimes make choices that cost them. TINL does not stop an adult making a choice about their own wallet. It warns clearly, in plain words, and it records what they chose.

The rule: every action you take is recorded before it takes effect. If it cannot be recorded, it does not take effect, and you stay where you were.

Under that rule TINL stops a request in exactly two cases: you set it to stop requests like that one, or TINL itself cannot run safely on your device. It never stops a request on its own judgment of what you should do.

The record is what makes that fair to both sides. A warning you went past, a warning you switched off, and a stop you asked for can each be traced to the choice you made, and when you made it.

Each row says whether that part is built today. Built means it is in the browser extension's code and tested end to end in a real browser; it is not yet in an extension release you can install.

The receipts service is live at receipts.a3e9.com and a release build sends to it, proven end to end on 17 September 2026. Until a release is published, no records leave anyone's device.

What you see, what you can do, and what is recorded, in each situation
SituationSituation What has just happened, from TINL's side, when a site sends a request to your wallet.You seeYou see What TINL's window shows you in that situation, if anything. Whenever the request goes ahead, your wallet's own confirmation still follows.You canYou can The choices open to you. Where there is a default, it is to cancel.RecordedRecorded What is written down before your choice takes effect. If it cannot be recorded, it does not take effect, and you stay where you were.StatusStatus Whether that part exists in code today. Built: in the browser extension's code and tested end to end in a real browser, not yet in a release you can install. Being built: decided, not yet written. Not live yet: written, and not running where it would have to run to count.
TINL finds nothing to flagTINL finds nothing to flag No rule in the active profile fired against what TINL could read. That is not a verdict that the request is safe; your wallet's own screen is still the last check.Nothing from TINL. Your wallet's own confirmation appears as usual.Sign or refuse in your wallet.What TINL decided.Built
A warningA warning TINL advises; it does not decide for you. Cancelling is the default, and continuing needs a deliberate tick so the choice on record is yours.What the request does, why it is risky, what can happen after you sign, and that TINL is advising: your wallet's own screen is still the last check.Cancel, which is the default. Continue, once you tick that you understand the risk and accept the consequences.The warning, the text you were shown, and whether you cancelled or accepted.Built
An oversized permission, such as unlimited spendingAn oversized permission, such as unlimited spending The site asked for more than the action needs. A smaller amount limits what the site can take later, without another signature from you.What the site asked for, a smaller amount instead, and what each amount lets the site do later.Grant nothing, grant an amount you type, or cancel. Granting everything the site asked for needs the same tick as a warning.Which amount you chose, and your acceptance if you chose everything.Built
TINL could not check the request (its service was unreachable, or it could not read the request)TINL could not check the request (its service was unreachable, or it could not read the request) Not checked is not the same as judged safe or unsafe. TINL says so plainly and leaves the choice to you, with cancelling as the default.That the request has not been checked, so it has not been judged safe or unsafe, and why.Cancel, which is the default, or continue after ticking that you accept the consequences.That it could not check, and what you chose.Built
TINL may have been tampered with on this deviceTINL may have been tampered with on this device One of the two cases where TINL itself stops a request: it cannot run safely here. A choice made on a device that may be compromised would prove nothing, so reinstalling is the way back.That TINL cannot run safely here, and to reinstall it.Nothing from TINL's window. A choice clicked on a device that may be compromised proves nothing, so none is offered.That TINL stopped, and why.Built
A stop you asked forA stop you asked for The other case where a request is stopped: a setting you chose, such as "stop instead of warning". There is no accept-the-risk override; you undo a stop by changing that setting, and the change is recorded.That the request was stopped because you set TINL to stop requests like it, and which setting did it.Close it, or change that setting.The stop, with the setting you had in force.Built
You switch a warning offYou switch a warning off Loosening a protection is a choice like any other. It needs your confirmation, and it is recorded before it applies.What you will no longer be warned about: "don't ask again" for a spender, turning stops off, a less strict profile, a higher per-site limit, or a different service address.Confirm or cancel. The setting changes only once your confirmation is recorded.The setting, what it was, and what it became.Built
A request goes through without a warning because you switched it offA request goes through without a warning because you switched it off Each request a setting lets through is recorded against that setting, so what happened traces back to the choice that allowed it.Nothing, as you chose.—What TINL decided under the setting you chose, tied to the record of that choice. Each request let through by "don't ask again" is recorded on its own.Built
Your settings from before this record existedYour settings from before this record existed A one-time snapshot, so the record starts from the settings you actually had rather than from nothing.Nothing.—Your settings as they stand, once, before the first thing the new version records.Built
Your records reaching A3E9Your records reaching A3E9 Records are countersigned by a separate receipts service, and A3E9's ledger keeps hashes only. No record leaves anyone's device until an extension release is published.Nothing.—Each record is signed on your device and countersigned by A3E9's receipts service at receipts.a3e9.com, which keeps only hashes on its ledger: the envelope carries no site and no address, and the detail behind it is encrypted under a key belonging to your device alone, which A3E9 can delete at your word. The service went live on 17 September 2026 and a browser extension built for release sends to it. Nothing reaches it from an extension you can install today, because no release has been published.Not live yet

Recorded in the browser extension's code today, before anything takes effect:

  • Every decision TINL makes, with the settings it made it under.
  • Your answer to a warning, with the sentence you ticked to accept the consequences. If that cannot be recorded, the request is cancelled.
  • Which amount you chose for an oversized permission, and your acceptance if you chose everything.
  • "Don't ask again", with its own acceptance, and each later request it let through.
  • Every change to a protection setting, before it applies. Loosening one needs your confirmation first.
  • Closing TINL's window without answering, which cancels the request.

// DECISION_RECORD

  1. 2026-09-16A wrong stop is a liability, and so is a person who went past a warning and later says nobody warned them. Both are answered by recording what the person chose.
  2. 2026-09-16Records are written by a separate receipts service, not by TINL itself, and only hashes go on A3E9's ledger. The details are kept encrypted under a key per device, so a person's details can be erased by deleting that key.
  3. 2026-09-16TINL does not stop people making choices about their own wallets. It warns and records. A stop happens only because the person set one, or because TINL cannot run safely on the device.
  4. 2026-09-16There is no "accept the risk" override of a stop. A stop is already the person's own choice; to undo it, they change that choice, and the change is recorded.
  5. 2026-09-16Switching a warning off is a choice like any other: confirmed, recorded before it takes effect, and every warning it later skips is recorded against it.

// WHERE_TINL_SITS

TINL is one of five. Audits make code safe to ship; these make it safe to touch.

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.

TINLthis page

Transaction Intent Normalization Layer

Decodes what a transaction or signature actually does before it is signed, and applies policy to the decoded intent.

Pathfinder

Execution-path assurance

Evaluates contract execution paths and issues verdicts, with decision memory and revalidation.

Sentry

Governance Sentry

Watches pre-proposal state through destination-chain execution to catch capture inside the timelock window.

Governor

Oracle Governor

Owns the inputs — what each source may establish, how fresh, how independent, and what happens when it goes dark.

a3e9-ledger

The evidence chain

The append-only record every verdict, correction and expiry is written to.

Safe to Touch — the whole line, and what it does not cover

// FROM_KNOWN_EXPLOITS_TO_TINL

Most losses are not new. This is how exploit history reaches TINL.

A one-off exploit rarely stays one-off. A 1-day or n-day attack reuses a flaw that is already public: the same vulnerable contract copied by another project or onto another chain, or a close variant the original fix was too narrow to cover. a3e9 turns each real incident into something it can look for again, so the next copy can be caught before anyone signs a transaction that touches it.

Where AI fits: a model can sort, propose and explain. It never decides. A family a model suggests is a note, a variant a model proposes is a hypothesis until a deterministic test and a monitoring rule prove it, and no model output changes a TINL decision on its own.

Each step says whether it runs today. Most of the AI half is not built yet, and this page does not describe it as if it were.

  1. 01

    Hearing about an incident

    Security alerts posted publicly are read as they appear and kept verbatim.

    AIA model sorts each alert into one of the exploit families a3e9 tracks, with a confidence. That is recorded as a note on an unconfirmed record, never as a finding.

    Running internally
  2. 02

    Turning an incident into a pattern

    Each confirmed incident is tied to the contract code that was exploited, and reduced to the flaw behind it.

    AINone. This is done by rules and people.

    Running internally
  3. 03

    Generating the variants

    Each pattern is varied along set axes, so one historical exploit becomes a family of related attacks to look for.

    AINone today. Variants are generated by rules.

    Running internally
  4. 04

    Models proposing new variants, and fixes that were too narrow

    Suggest variants the rules did not, and spot a patch that closed one path while leaving the same flaw reachable another way.

    AIThis is the model's job once built. Each proposal would be a hypothesis, checked by a different model and proven by a deterministic test before it counts.

    Not built
  5. 05

    Finding copies of exploited code

    Pathfinder flags a contract whose code is byte-for-byte the same as code that was already exploited, on any chain and at any address.

    AINone. Exact code matching.

    Built, not running
  6. 06

    Finding forks, recompiles and patched copies

    Match code that differs in bytes but carries the same flaw.

    AINot decided yet whether this needs a model.

    Not built
  7. 07

    Reaching a signing decision

    TINL's service asks Pathfinder for a verdict when it reviews a transaction's execution path or simulated outcome, so a match can keep a desk from touching a copy of exploited code. The browser extension's checks do not ask Pathfinder.

    AINone. The verdict is Pathfinder's deterministic answer.

    Built, not running

In the browser extension today, known-attacker protection comes from a different source: TINL checks the spender or operator of a permission against a known-drainer list you point it at, and warns when it matches.

Variants, 1-day and n-day, in depth Where the AI is, and what it may never do

// WHAT_TINL_IS · WHAT_IT_IS_NOT

An authorization-safety layer, behind an action that already exists

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.

  • Not a cryptocurrency, exchange, marketplace, token, or investment product.
  • Not a wallet, and not a replacement for one — TINL never holds a key and never auto-signs.
  • Not a store, a payment rail, or a substitute for platform commerce and entitlements.
  • Not a new app, screen, or account a player has to visit, create, or remember.

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

The rules this product is built and described by.

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

“Claim your tournament skin” versus an unlimited approval

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.

## The order the steps happen in, from the player pressing the button to the optional shared indicator. This is a worked example for a testnet or controlled environment, not a recorded result.What happensWhat happens The event at this step: what the player, the game's integration or TINL does, in the order it occurs.What TINL checksWhat TINL checks What is looked at or recorded at this step. TINL evaluates the request and the context handed to it. It cannot by itself see the message or the link that brought the player to the page.ResultResult What is true once the step is done. Nothing is signed or broadcast before the decision, and nothing is approved unless the player chooses to go ahead.
1The player presses the existing “Claim reward” button.Step 1 The declared action is what the player believes they are doing. Recording it first is what lets TINL compare the real request against it.The declared action is recorded: claim one event item.There is now a baseline for what the person expects.
2The integration hands the proposed authorization to TINL before the signer sees it.Step 2 TINL sits before the signer, inside the flow the game or wallet already owns. It never signs anything itself and is never handed a private key.Exact request bytes, account, chain, origin and session context.Nothing has been signed or broadcast.
3TINL decodes the real effect.Step 3 Decoding turns the request's bytes into what they would do: here, a permission grant with a spender, an amount and an expiry, not the claim the page described.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.
4TINL compares the declared action with the decoded effect.Step 4 A declared-intent mismatch: the request does something broader than the action the player chose. A reward claim should not create a spending permission.A reward claim should not create a broad spending permission.Declared-intent mismatch.
5TINL checks the target and context.Step 5 TINL checks who would receive the permission against what the event is expected to use. Here the spender is not a verified event service.Expected event manifest, code identity, origin and state snapshot.The spender is not a verified event service — target unverified.
6TINL applies the hard limits.Step 6 An unlimited amount with no expiry lets the spender move that token at any later time, with no further signature.Permission breadth and lifetime: the amount is unlimited and the expiry absent.Unbounded authority.
7TINL returns WARN with reasons, not a generic error.Step 7 Reason codes travel with the decision so the host can explain it, instead of showing a generic error. WARN is the default. A request is stopped only by a recorded choice (the person's own "stop instead of warning" setting, or an institution administrator's policy) or because TINL cannot run safely on the device. Otherwise TINL warns and the person decides.Reason codes travel with the decision so the host can explain it.The player sees why before anything is signed. Where a recorded choice says stop — the player's own setting, or an administrator's policy — the signing adapter receives no candidate request at all.
8The host renders its own normal safety language.Step 8 TINL returns a decision; the host explains it with its own existing error component and design language.No blockchain lecture — the product's existing error component.Nothing is approved unless the player, now told what the request really does, chooses to go ahead.
9A privacy-minimized decision record is written locally.Step 9 The record is privacy-minimized: a hash stands in for the request, and no seed phrase or key is ever written.Request hash, policy version, reason codes, time. Never a seed phrase or a key.Support and incident review have evidence.
10Optionally, and only with consent, a pseudonymous indicator is shared.Step 10 Nothing is shared unless the person consents, and then only the malicious target's fingerprint, never anyone's secrets.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 is explained before it is approved, and stopped where a recorded choice says so.

// SAFETY_API · A_SMALL_SERVICE

A small safety service on an action you already own

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

Start small, inside something that already exists.

The best early integration is not a system-wide Steam or Xbox 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.

PlatformPlatform The kind of product TINL would sit inside. Live · UAT marks the one placement exercised today, the wallet connection, through the Chrome extension. Model marks a described pattern and nothing more.Where TINL sitsWhere TINL sits The moment in that product's own flow where TINL would check a request: before one high-consequence action, not across the whole platform.What the player keepsWhat the player keeps What the player already uses and keeps using unchanged. TINL adds a check; it does not replace the product's screens, account or payments.What TINL must not changeWhat TINL must not change The boundary: rules the platform publishes for everyone, which this product must stay inside. These rows are limits, not partnerships. None of these platforms is a customer, a partner or a live integration.
Wallet or connection providerWallet or connection provider The only placement exercised today. The Chrome extension checks a request before MetaMask or Phantom shows its own confirmation, and is ready for independent UAT. The wallet's screen, and the final say on it, stay with the person.
Live · UATThe Chrome MV3 extension is ready for independent UAT on this placement.		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 serviceGame account service A game's own service would ask TINL before issuing a high-consequence request, and render the answer in the game's own design. A model, not a live integration. The platform is not a customer or a partner, and no conversation with it is claimed.
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.
Steam / PC distributorSteam / PC distributor Publisher-side, or a non-blockchain safety-training module. A Steam build would contain no wallet, chain or token path at all; Steam is not a wallet or blockchain pilot. A model, not a live integration. The platform is not a customer or a partner, and no conversation with it is claimed.
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.
Xbox / consoleXbox / console A check inside one title's own game service. It is not a system-wide Xbox feature. A model, not a live integration. The platform is not a customer or a partner, and no conversation with it is claimed.
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 / QuestMeta / Quest A check inside one app's own account or permission layer, staying within Meta's payment, anti-fraud and real-world-value restrictions. A model, not a live integration. The platform is not a customer or a partner, and no conversation with it is claimed.
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, embedded wallet, game account service, a Steam-compatible non-blockchain safety module, and a console game service. Only the browser wallet connection is live today. The other four are patterns this page describes and nothing more.

// LIVE_TODAY · VERSUS · THE_INTEGRATION_MODEL

Two columns, kept apart on purpose.

Live today — an evaluator can run this

  • Chrome MV3 extension, ready for independent UAT against MetaMask (EVM) and Phantom (Solana).
  • BLOCK enforced when the provider wrap is on the path — a blocked request never reaches the wallet.
  • WARN and NORMALIZE advisory as a whole against a hostile page; the wallet confirmation is the backstop.
  • Price-impact rules remain in the policy engine and still classify a swap the decoder can read. Every surface that demonstrated them — the product page, the portal tab and its UAT — is withdrawn, so nothing here offers it as something to exercise.

Model, not shipping — none of this exists yet

  • —A declared-intent field on the API — the running evaluator endpoints have no such field.
  • —A child-safe engine profile — the engine ships retail_strict, trader_balanced and dev_passthrough.
  • —Steam, Xbox and Meta placements — patterns inside published platform rules, not hooks that exist.
  • —Signed creator-event manifests for verifying an event's own target identity.
  • —A permission inventory showing what standing authority an account has already granted.
  • —Executor-side receipt verification, re-checking the exact bytes at the moment of signing.

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:

  • It does not prevent all phishing.
  • It does not discover every malicious website.
  • It does not detect all device compromise.
  • It does not reverse completed transfers.
  • It does not guarantee reimbursement.
  • It does not replace platform payments.
  • It does not substitute for moderation or identity systems.

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 and a model for where the layer sits. It is not a production or procurement claim.

// READ_NEXT

The two implemented surfaces, and the procedures that test them.

Wallet Scams — what ships

The implemented browser surface: the attack patterns it has rules for, the plain-language limits, and the roadmap that closes the remaining gaps.

Safe to Touch — the whole assurance line

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.

UAT procedure — Chrome

The full browser acceptance test, ungated, with the expected decision at every step. Reading it needs no token.

A3E9 TINL — Intent Before Signature

The Chrome extension and the policy engine behind it. BLOCK versus advisory WARN/NORMALIZE is stated, and Price Impact is described as a rule surface rather than a fourth product.

TINL — Threat Model and Safeguards

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.

All published documents

// WHO_IT_IS_FOR

One sentence each, in their own words.

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.”

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

What can be evaluated today, and how strongly

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.

Enforcement strength by surface and decision
SurfaceSurface Where TINL runs. The same decision can be imposed with different strength on different surfaces, so each surface is its own row.StatusStatus The claim status of this release, as a word. UAT means available only inside the defined evaluation process and scope.BLOCKBLOCK BLOCK means the request does not reach the wallet. This column says whether the surface can actually impose that. HardIntercept: the request is not passed to the signer, and is the only strength that stops anything. AdvisoryOnly: the host is told, and a hostile page can ignore the answer. EvaluatorOnly: observed on A3E9's own surface, not evidence about a third-party wallet. Unavailable: not on this surface.WARNWARN WARN means the person is told why and chooses. This column says how firmly that answer holds on the surface. HardIntercept: the request is not passed to the signer, and is the only strength that stops anything. AdvisoryOnly: the host is told, and a hostile page can ignore the answer. EvaluatorOnly: observed on A3E9's own surface, not evidence about a third-party wallet. Unavailable: not on this surface.NORMALIZENORMALIZE NORMALIZE means a smaller permission is offered in place of the one asked for. Like WARN it asks for consent, so it is advice wherever a page can ignore the answer. HardIntercept: the request is not passed to the signer, and is the only strength that stops anything. AdvisoryOnly: the host is told, and a hostile page can ignore the answer. EvaluatorOnly: observed on A3E9's own surface, not evidence about a third-party wallet. Unavailable: not on this surface.
chrome_mv3chrome_mv3 The Chrome browser extension (Manifest V3), with MetaMask and Phantom. It wraps the wallet provider on the page, so it can hold a request back only where that wrap is on the request path. A page that reaches the wallet another way is not intercepted.2026.08UATHardInterceptThe 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.
evaluator_webevaluator_web A3E9's own evaluator portal, on testnets with evaluator-controlled accounts. It demonstrates the decision path. It is not evidence about any third-party wallet or hostile page, and its results must not be described as protection delivered to an end user.2026.08UATEvaluatorOnlyObserved 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

CURRENT
In the named build, with evidence for this exact statement.
UAT
Available only inside the defined evaluation process and scope.
RETIRED
No longer supported. Do not use.
NON-CLAIM
Explicitly outside what TINL does.
TARGET
Approved target architecture. Not implemented, and not an endpoint.
MODEL
Illustrative. Not a live integration.

Decision states

Four answers, and the case where there is no answer

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.

CURRENT

Four decisions: ALLOW, WARN, BLOCK, NORMALIZE

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 fired. It is not a statement that a transaction is safe or that its outcome is guaranteed.
  • How strongly each decision can be imposed varies by surface. WARN is never a waiver of a hard policy.
TINL UAT procedure — Chrome / portal
NON-CLAIM

ALLOW is not a safety verdict

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 swap outside the coverage release reaches ALLOW without ever being priced.
MODEL

Worked example — an unlimited approval, normalized

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

  • Illustrative, on a testnet, with an evaluator-controlled account. Not a live personal-wallet evaluator.
TINL UAT procedure — Chrome / portal
TARGET

Target: a declared-intent host contract

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

  • This is an integration model, not an endpoint you can call today.
  • No current evaluator route accepts a declared-intent field.

Coverage

What is assessed, and what passes through unassessed

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: 53442/53483 (99.92%) of authorization transactions decoded to a specific intent

Decoded and assessed

  • ERC-20 approve, and the distinction between a bounded amount and an unlimited one — the signal a drainer depends on
  • ERC-20 transfer, and transferFrom with a self-pull distinguished from a third-party pull
  • ERC-721 and ERC-1155 setApprovalForAll, and its revocation
  • ERC-721 and ERC-1155 safeTransferFrom, including the batch form
  • The EIP-2612 permit signature path, which never becomes a transaction and so is invisible to on-chain sampling
  • Plain native ETH payments — empty calldata, no contract invocation
  • ERC-4337 eth_sendUserOperation, evaluated against the same rule table

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.

  • Permit2 approve and permitTransferFrom — Uniswap's allowance contract, not the ERC-20 one
  • increaseAllowance and decreaseAllowance, which raise an allowance without an approve
  • Any authorization expressed through a contract this decoder has no typed decode for; those reach the unknown-selector rule and warn rather than passing silently

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

  • Uniswap V2 router swapExactTokensForTokens on a direct two-token path
  • SushiSwap router swapExactTokensForTokens on a direct two-token path, derived against SushiSwap's own factory
  • Single-pool trades through the Uniswap V3 SwapRouter, where the pool is resolved from the verified venue table using the fee tier the trade itself names
  • The whole Uniswap V2 exact-input family, not one entrypoint of six — including the ETH-in forms, whose amount comes from the transaction rather than the calldata, and the fee-on-transfer variants
  • Trades wrapped in a router batch call, unwrapped one level and priced when the batch contains exactly one readable swap
  • Uniswap Universal Router V2, V3 and V4 commands, unwrapped from its packed command stream and from V4's own nested action stream
  • Uniswap V4 single-pool trades on pools without a hook, read out of the PoolManager singleton's storage — V4 has no per-pool contract, so a pool is identified by the hash of its key rather than by an address
  • Single-pool trades through the Uniswap V3 SwapRouter02, which describes a trade differently from the router above and is therefore read separately rather than assumed to match

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.

  • Pricing a Uniswap V3 trade in the offline embedded build (Mode A). The pool is identified there, which is what makes the trade COVERED here, but scoring a concentrated-liquidity venue needs live data about the liquidity bands around the current price, and only the service build (Mode B) can obtain it. In the embedded build a covered V3 trade is still detected and not priced.
  • Uniswap's Universal Router — 260 of the 964 unread router transactions in this sample, and the single largest remaining gap. It packs its instructions in a form this engine does not yet read, so the trade is recognised as being routed and deliberately not guessed at.
  • Trades wrapped in a router's batch call — 105 transactions in this sample — including V3 trades that are perfectly readable once unwrapped
  • Uniswap V3 and V4 trades that hop through more than one pool, and exact-output trades on either — this engine simulates exact-input only
  • Batches containing more than one swap. A batch of two trades is not one trade, and pricing either would describe a fraction of the transaction as though it were all of it.
  • Any Uniswap-V2-style fork whose router this engine does not recognise. The venue determines which pool a trade lands in, so an unrecognised fork resolves to NO pool and is detected but not priced — never to a lookalike pool at another venue
  • Wallet-vendor and aggregator routers: MetaMask Swap, 1inch, KyberSwap, CoW, ParaSwap, 0x, Odos
  • Multi-hop V2 trades. A route through more than one pool compounds impact across all of them; the trade is detected but no figure is produced
  • Any trade whose pool data cannot be read at the moment of decision. Nothing is escalated and the trade is allowed — an unread pool must never be presented as a checked one

Non-claims

What TINL does not do

NON-CLAIM

What TINL does not do

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

  • No universal phishing prevention.
  • No device-compromise detection.
  • No transfer reversal and no reimbursement guarantee.
  • No payment-rail bypass and no wallet replacement.
  • No universal enforcement.
CURRENT

No key, no seed, no custody authority

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

  • If any screen asks for a key or a seed phrase, that is a defect. Stop and report it.
Boundary: A3E9's software, the vendor module's, and what neither claims

Evaluator access

Requesting access to the gated UAT

UAT

What a UAT evaluator may submit

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

  • No step asks for a private key or a seed phrase.
  • Results are evaluator-only unless a named controlled adapter proves hard interception on the surface under test.
TINL UAT procedure — Chrome / portal1 further artifact available to approved evaluators
CURRENT

Request evaluator access

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

  • The request is not a security control. The invitation grant and the authorization layer behind it are.
  • Do not submit a seed phrase, a private key, a recovery phrase, or unredacted production transaction intent.
TINL UAT procedure — Chrome / portal
Request evaluator access