Glossary

Agentic Finance

A paradigm of financial systems where autonomous software agents (often powered by AI) carry out financial operations (like trading, payments, lending) with minimal human intervention. In agentic finance, agents have the ability to reason and make decisions, requiring new trust and safety frameworks since traditional controls assume human oversight.

t54 Platform

The AI Agent payment platform for which tRadar is the risk control infrastructure. t54 provides the environment where AI agents can initiate and process payments (and possibly other financial transactions). The name “t54” refers to the overall system encompassing agent APIs (often called tPay), the risk control layer (tRadar), and the code audit layer (tAudit). It is designed to enable a new generation of financial applications driven by AI.

tRadar

The real-time transaction risk control system of the t54 platform. tRadar monitors and validates transactions in real time using a multi-layered approach: from static rules to a network of validator agents. Its primary goal is to detect and prevent fraudulent, anomalous, or unsafe transactions before they are executed, without human intervention in the loop (unless needed via challenges). The name implies a “radar” for threats in the transaction flow.

tAudit

The code audit component of the t54 platform. tAudit complements tRadar by auditing the code (smart contracts, agent code functions) that agents use to execute transactions. It provides a score or feedback on code security and quality. tRadar uses tAudit’s outputs (e.g., function hash whitelisting) to increase trust in transactions that originate from vetted code.

Validator-Agent Network (VAN)

The decentralized network of AI validator agents that collaboratively assess transaction risk. Instead of a single validator, VAN comprises multiple validators, each of which is an autonomous agent or AI model analyzing transactions. They vote or come to consensus on whether a transaction is safe. The VAN introduces committee-based decision making to risk control, including mechanisms for weighted voting, consensus, and conflict resolution among validators.

Validator (Agent)

An individual validating entity within the VAN. In tRadar’s context, a validator is often an AI-driven agent (or a service run by a person/organization using an AI model) that evaluates transactions. Validators have a stake (or delegated stake) in the system and earn rewards for correct behavior. They produce a verdict (approve/challenge/reject) for each transaction they evaluate and are subject to slashing for malicious or poor performance.

Delegator

A stakeholder who does not run a validator themselves but supports the network by delegating (staking) their tokens behind a chosen validator. By doing so, the delegator increases the validator’s weight (influence) in the consensus. In return, the delegator receives a portion of that validator’s rewards. Delegators help decentralize the network’s trust and give community members a way to participate in governance and earning without directly operating a validator node.

Stake (Staking)

In this context, an amount of cryptocurrency or token locked up to secure the behavior of validators. Validators must stake tokens as collateral – if they misbehave, these tokens can be forfeited (slashed). Stake also determines voting weight in many proof-of-stake systems. Delegators “stake” by bonding their tokens to validators. Staking aligns economic incentives, as one risks losing value if the associated validator acts against the network’s interest.

Slashing

A penalty mechanism that confiscates a portion of a validator’s staked tokens when the validator violates the rules. For example, if a validator approves a fraudulent transaction or is caught colluding, a predefined slashing condition is triggered and some of its stake is destroyed or redistributed as a penalty. Slashing is meant to strongly discourage misconduct by ensuring validators have skin in the game.

Sequencer

The coordinator component in tRadar that sequences (orders) transactions and orchestrates their validation by the network. The sequencer receives incoming transactions from the t54 platform, runs initial rule checks, distributes validation tasks to validators, and aggregates their responses into a final decision. It essentially “sequences” the steps of validation and ensures a consistent ordering and handling of multiple transactions. In the current design it’s a service run by the platform, but future plans involve decentralizing this role among the validators or via a consensus protocol.

Challenge (Request)

A mechanism by which tRadar asks for additional information or verification for a transaction that is deemed risky or unclear. When a transaction is challenged, the client agent (or user) must provide extra data – for instance, an explanation or documents – via the API. The transaction will be re-evaluated with this new information. Challenges serve as an intermediate state between approval and rejection, allowing potentially legitimate transactions to be salvaged with proper justification.

Risk Level (LOW, MEDIUM, HIGH, CRITICAL)

Categories used by tRadar to classify the risk associated with a transaction.

LOW typically means the transaction is safe to auto-approve. MEDIUM means some caution is warranted – additional info or validation needed (often triggers a challenge or manual review). HIGH indicates a serious concern – likely involving stringent validation and possibly manual oversight or multi-agent consensus. CRITICAL means the transaction is almost certainly malicious or violating fundamental rules, leading to automatic rejection.

These levels may correspond to numeric scores under the hood, but are presented as tiers for clarity.

Trace Context

The data capturing the AI agent’s state and thought process at the time of transaction. This can include the sequence of steps the agent took, decisions made, tools invoked, and intermediate reasoning. tRadar leverages the trace context to give validators deep insight into why the agent is initiating the payment, helping them detect if an agent might be compromised or making an irrational decision.

Function Call Stack Hashes

A list of hashes representing the code functions that were executed before the payment. Each hash corresponds to a specific function version, which can be cross-checked with tAudit records to confirm the code is audited and safe. This effectively creates a chain of custody for the transaction – if the call stack includes only trusted functions, the transaction is more likely legitimate. Validators consider this when evaluating risk (e.g., an unknown or un-audited function hash might raise suspicion).

Defense-in-Depth

A security design principle embraced by tRadar where multiple layers of defense are applied. Even if one layer (say the rule engine) misses something, the next layer (validator consensus) can catch it, and even beyond that, the challenge mechanism or manual oversight can intervene. This layered approach significantly reduces the probability of a malicious transaction slipping through, as it would need to evade several independent safeguards.

Composability

In the context of software and blockchain ecosystems, composability refers to the ease with which components can be combined or integrated into larger systems. tRadar is described as composable because its modules (rules engine, validator network, challenge system) can be adapted to different scenarios, and external platforms can potentially hook into tRadar’s functionality. It’s built in a modular way, allowing it to serve as a plug-and-play security layer across various agent-driven financial applications.