Key Terms
A glossary of the terms used across the Nava API, SDK, and dashboard.
Lifecycle Overview
A proposed action can move through four distinct phases. Guardian participates in verification only: it does not authorize, sign, or submit an action. The integrating builder owns the later authorization and execution phases.
- Proposal: the agent constructs a structured action and submits it for review.
- Verification: Guardian evaluates the action against the active policy and returns a verdict.
- Authorization: a user or service authorizes execution, if the builder's workflow requires it.
- Execution: the builder signs and submits an approved action to the target chain or protocol.
A request can finish with a rejected verdict, or pass verification and still
fail later during builder-managed execution. Fields for those phases should be
handled independently.
Proposal
Verification request
The package an agent submits to Nava for review.
Request hash
The requestHash field is the unique identifier used to look up a request and
its verdict. It is not the same as an on-chain transaction hash.
Intent
Optional human-readable or structured context describing the action's goal. Guardian's live deterministic approval path evaluates the structured proposed action against the active policy; it does not decide whether an action matches free-form intent text.
Proposed action
The structured action submitted for review. The current API sends it in
proposedTx. The current foundation
decodes and checks Uniswap transactions. Hyperliquid action support is
Developer Preview.
Decoded transaction
A parsed, human-readable view of an EVM-shaped proposed action.
Verification
Verification verdict
Guardian's policy decision for a request. The authoritative outcome is one
of:
pending: evaluation has not reached a terminal result; keep the action paused.approved: the proposed action satisfies the evaluated policy; the builder may continue its own signing and venue-submission flow.rejected: the proposed action violates the evaluated policy; do not submit it.
Verification trace
The structured record of which checks ran, their inputs, and their outcomes. It explains a verdict and can support a request-detail view.
Check result
Each checks[] entry records the outcome of one deterministic policy check. It
identifies the check and records a status such as passed, failed, or
not_checked, plus an explanation.
Primary failure
The reasonCode field is the top-level machine-readable reason for a pending or
rejected verdict. Use the human reason and triggering policy field when present
to provide more context.
Verification policy
The versioned policy used to evaluate the request. Verdict metadata identifies
the evaluated policyVersion when available.
Verification record
The database-backed artifact for a request, including its proposed action, verdict, evidence, and metadata. It supports service lookups; it is not an on-chain transaction.
Authorization
Execution approval
An authorization decision in the builder's workflow after a successful Guardian verdict, when explicit sign-off is required. This is separate from Guardian's policy verdict.
Execution
Execution mode
Defines which user, agent, or service is responsible for signing and submitting an action after verification. Guardian does not perform this step.
Execution status
Where a builder-submitted action is in its target venue's lifecycle, for example not started, submitted, confirmed, or failed. This is separate from the Guardian outcome.
Transaction hash
The on-chain transaction hash for an executed blockchain action. It is distinct from the Guardian request hash.