Skip to main content

Key Terms

A glossary of the terms used across the Nava API, SDK, and dashboard.

Lifecycle Overview​

A transaction handled by Nava moves through four phases. Each phase has its own state, and the API exposes them on separate fields.

  1. Proposal: the agent constructs an action and submits it for review.
  2. Verification: the Arbiter evaluates the action against the active policy and returns a verdict.
  3. Authorization: a user or service authorizes execution, if the policy requires it.
  4. Execution: the action is signed and submitted to the target chain or protocol.

A request can complete verification with a REJECTED verdict, or pass verification and still fail during execution. The fields below describe each phase independently.

Proposal​

Verification request (verificationRequest): the package an agent submits to Nava for review.

Request hash (requestHash): the unique identifier for a verification request. Used to look up the request, its verdict, and its trace. This is not the same as the on-chain transaction hash.

Intent (intent): the goal the action is meant to satisfy, expressed in natural language or as a structured object. The Arbiter checks the proposed action against the intent.

Proposed action (proposedAction): the action submitted for review. May be an EVM transaction, a typed-data payload, or a non-EVM protocol action (for example, a Hyperliquid order or a Polymarket position).

Decoded transaction (decodedTransaction): a parsed, human-readable view of the proposed action. Present only when the action is EVM-shaped.

Verification​

Verification verdict (verdict): the Arbiter's final answer for a request.

  • APPROVED: the proposed action satisfies the policy.
  • REJECTED: the proposed action violates the policy.

Verification status (verificationStatus): where the request is in the Arbiter's processing pipeline.

  • PENDING: accepted and being evaluated.
  • COMPLETED: evaluation finished (a verdict is available).
  • ERRORED: a system-level fault stopped processing.

Verification trace (verificationTrace): the structured record of which checks ran, their inputs, and their outcomes. Used to explain a verdict and to power the dashboard's request detail view.

Check result (checkResults[]): the outcome of a single check inside the trace. Each entry includes a checkId, a category, a result (PASS, FAIL, SKIP, or ERROR), and a short explanation.

Primary failure (primaryFailure): the most significant failed check on a rejected request. Surface this when you only have room to show one reason.

Failed checks (failedChecks[]): the full list of failed or blocking checks for a rejected request.

Verification confidence (confidence): the Arbiter's confidence in a verdict or check result, on a 0 to 1 scale.

Verification policy (verificationPolicy): the versioned policy used to evaluate the request. Includes a policyId and a version.

Verification record (verificationRecord): the persisted artifact for a completed request: the request itself, the verdict, the trace, and metadata. This is what is returned by historical lookups and recorded on NavaChain.

Authorization​

Execution approval (executionApproval): a separate authorization step that runs after a successful verification, when the policy requires explicit sign-off from a user or service before execution. The status field takes one of PENDING, GRANTED, or DENIED. Omitted when the policy does not require approval.

Execution​

Execution mode (executionMode): who reviews and submits the action.

  • USER_DIRECT: the user signs and submits without Arbiter review.
  • USER_REVIEWED: the Arbiter reviews; the user signs and submits.
  • AGENT_REVIEWED: the Arbiter reviews; the agent signs and submits.

Execution status (executionStatus): where the action is in the on-chain lifecycle.

  • NOT_STARTED: execution has not begun.
  • SUBMITTED: broadcast to the network.
  • CONFIRMED: included on-chain successfully.
  • FAILED: execution did not succeed (rejected, reverted, or never broadcast).

Transaction hash (transactionHash): the on-chain transaction hash for an executed action. Distinct from the request hash.