AURA Guard: Address Intelligence

Every stablecoin app can hold and send. One thing nobody has solved:

"I pasted an address and the money is gone."

Wrong chain, wrong token, a typo, a sanctioned counterparty, an address that cannot receive that asset. Billions lost, no recourse, and it is the single loudest reason ordinary people will not touch this. AURA Guard is the answer, and it is the reason to choose AURA over a wallet.

Before a single unit moves, the recipient is checked for validity, format, which "bank" it belongs to, which currencies it accepts, sanctions status, and behavioural risk, and the result is explained in language a person acts on:

"Sarah's account is at a different bank, and it can't receive US Dollars. Ask Sarah for an account at Base, or send Euros instead."

Not "invalid recipient for selected network."

The check pipeline

flowchart TB
    IN["Address + declared network + currency"] --> F{Format valid?}
    F -- no --> RF["Refuse · explain the format problem"]
    F -- yes --> B{Declared network can settle?}
    B -- "no (e.g. Ethereum)" --> RB["Refuse · wrong-network loss prevented"]
    B -- yes --> A{Active / can receive this currency?}
    A -- no --> RA["Refuse · ask for the right account or currency"]
    A -- yes --> S{Sanctions / risk screen}
    S -- flagged --> RS["Refuse · watchlisted"]
    S -- clear --> OK["Clear · time-stamped, tier-aware"]

Each stage returns not a boolean but an explanation, what was checked, what it means, and what to do next. The engine never says "verified safe"; it says what it checked.

The wrong-network problem, and why AURA asks

Six of the nine supported networks share the EVM address format. An EVM address is identical at Base, Ethereum, Polygon, Arbitrum, Optimism, and BNB Smart Chain, the same key controls all of them. A format check alone therefore cannot tell Base from Ethereum, and AURA settles only at Base.

If Guard silently accepted a correctly-formatted address whose owner meant it for Ethereum, the payment would go to an account that never receives it, the category's defining loss. So the add-payee flow asks the user which network, and a declared network AURA cannot settle at is refused before any other check.

The whole argument for asking rather than inferring

The address cannot reveal which network its owner intended. Only the user's stated answer can. Asking is the one control that catches a valid-looking address at the wrong bank.

The picker reads its list from Guard's own registry rather than restating it, a picker offering a network the engine does not know is exactly how a wrong answer gets accepted.

Network	Address family	Settles today?
Base	EVM	✅ Yes
Ethereum, Polygon, Arbitrum, Optimism, BNB Smart Chain	EVM	Not yet
Tron (TRC20)	base58check	Not yet
Solana (SPL)	base58	Not yet

Format validation is deterministic, and that is the point

Address Intelligence is mostly not an LLM. A checksum either passes or it does not.

• EVM, length and EIP-55 checksum. A single mistyped character fails the checksum and is caught as "Almost right, but one character looks wrong."
• Tron, base58check, whose checksum is a double SHA-256. Guard carries a SHA-256 implementation verified against the NIST vectors (including the padding boundary cases). A single swapped character in a real Tron address is caught.
• Solana, base58 over the Solana alphabet; excluded characters (0, O, I, l) are rejected with a specific reason.

A differentiator that does not depend on model behaviour is exactly the one that can be trusted. The risk band, sanctions and behavioural scoring, is the only part that involves a model, and it is coarse on-chain (riskBand) to avoid leaking a provider's licensed data.

Fail closed, always

If the Guard service is unavailable, AURA refuses to add a payee or send, it never fails open.

A refusal is safe. A guess is not.

This is the opposite of the industry's usual instinct to degrade gracefully. For a payments product where the failure is irreversible loss, refusing to proceed is the graceful mode.

Where the trust state lives

Guard produces the analysis; the kernel holds the consequence. The AuraPayeeRegistry records each payee's coarse risk band, when it was last screened, and whether it is trusted, and the AuraSecurityManager hook can require a fresh screening before a transfer clears. Trust is time-bounded, enforced on-chain, and marking a payee trusted is a Tier-4 operation.