Skip to main content
SHIELD is the security policy layer behind NEAR Intents and the 1Click stack. It lets integrated services evaluate requests against incident state and shared security posture before continuing execution. Instead of relying on a single global stop switch, SHIELD is built for scoped response. Today that means request-time decisions such as allow, delay, approval, or block on integrated flows, with broader orchestration expanding over time.

Implementation status

Use this page as both a product direction overview and a status snapshot.

Live today

Incident submission and resolution, scoped permissions, security modes, and quote-time evaluation decisions for integrated Shield consumers.

Rolling out

Broader runtime adoption of Shield decisions across additional request paths and operational surfaces.

Vision

Multi-surface posture orchestration informed by richer operational, transaction, and chain-health signals.

Architecture

At its core, SHIELD is a dedicated incident and policy service. Authorized producers submit incidents, and integrated consumers query SHIELD to determine how a request should proceed. This architecture supports graceful degradation by applying scoped policy decisions at request time instead of immediately shutting down the full platform.

Incident ingress

One write surface for incident creation and resolution with authentication, scoped authorization checks, and auditable records.

Security mode

Shared posture represented as coarse modes (normal, paranoid, under_attack) that integrated consumers can apply consistently.

Policy decisions

Evaluate endpoints return concrete decisions (allow, delay, approval, block) based on incidents, posture, and configured thresholds.

Guarded surfaces

SHIELD can coordinate security posture across multiple parts of the platform:

1Click swaps

Live today for integrated quote-time checks, including scoped block, delay, and approval outcomes.

Bridge

Rolling out as Shield decisions are adopted across additional execution paths and bridge-touching flows.

Solver pool

Vision: solver and liquidity controls can consume the same incident and posture model as integration expands.

Public status

Live today through incident public descriptions that support partner-facing degraded-state messaging.

Security Modes

SHIELD defines three operational modes. They are intentionally coarse so they are easy to reason about under pressure.

Normal

No friction. This is the default operating state.

Paranoid

Buy time. Add delay windows and increase operational scrutiny while the situation is assessed.

Under attack

Pause affected functionality and monitor in depth while responders contain the incident.
The modes are designed to be simple on purpose. In an incident, operators benefit from clear posture changes more than they benefit from a large number of fine-grained states.

Partner Permissions

The SHIELD signal bus is open to multiple producers, including partner integrations, on-call operators, internal anomaly detection, and internal tooling. Producers do not inherit capabilities automatically. Each producer receives an explicit permission set. Typical capabilities include:

Block destination

Pause a single chain, token, or destination without escalating the whole platform.

Flag observation

Submit an observation for review without forcing a posture change.

Raise mode

Move a scoped surface or the full platform into paranoid or under_attack.

Read-only

Inspect status and history without changing platform posture.
These permissions are scoped. The model supports granular scope by chain, bridge, token, address, and security mode. Scope enforcement is rolling out incrementally. As newer request-evaluation paths adopt narrower chain-specific permissions, behavior may vary by integration path.

Example permission models

Internal incident responder

An internal on-call operator may be granted raise mode at platform scope so they can move the system into paranoid or under_attack while a real incident unfolds.

Consumer integration

A partner integration may be granted block destination at per-chain scope, plus read-only access elsewhere, so it can pause a chain it cares about without escalating the global posture.
Capabilities are auditable in both directions. Partners can inspect their own action history, while internal operators can review the full action set by partner, scope, or effect.

Anomaly Engine

SHIELD integrates a first-party anomaly engine as an additional decision input for quote evaluation. The engine is rule-based and explainable rather than model-driven. It maps observed conditions to concrete decision outcomes.

Current behavior

In current integration, anomaly scoring is applied on quote evaluation under configured thresholds and feature flags.

Severity mapping

Elevated outcomes can increase friction (for example delay or approval), while failures are handled defensively.
As integration expands, anomaly inputs can inform more surfaces beyond the current quote-centric path.

Transaction and Account Monitoring

Proactive intent security is not only about chain-level conditions. It is also about identifying when a specific transaction, account, destination, or fund flow looks unusual in the context of the broader system. SHIELD’s policy model is designed to support transaction and account-level targeting across connected chains, including:

Transaction-level anomalies

Today: integrated quote requests can be delayed, blocked, or routed to approval based on incident and anomaly outcomes.

Account and destination risk

Model support exists for scoped controls by recipient, sender, deposit address, and counterparties.

Suspicious flow of funds

Rolling out: broader use of policy decisions across more end-to-end flow checkpoints.

Scoped response

Vision: apply targeted friction to the transaction, account, route, or destination that needs attention without broad platform degradation.
This remains core to the SHIELD vision: proactive security should react not only to unhealthy chains, but also to suspicious activity tied to individual requests and participant accounts.
In practice, that means NEAR Intents can raise friction or require additional review for a specific flow of funds while the rest of the system continues operating normally.

Chain Health

Different chains fail in different ways. A proof-of-work chain may lose hashrate. A proof-of-stake chain may stall on finality. An L2 may fall behind its sequencer. SHIELD is being designed around a normalized health model. The target state is chain-family adapters that emit a shared output at the policy boundary.

One health vocabulary

Vision: each adapter answers shared practical questions such as block production, finality health, throughput envelope, and anomaly conditions.

Native adapters

Vision: each chain family stays native to its own environment while translating to shared policy semantics.
Common adapter families include:

Bitcoin / PoW family

Metrics such as hashrate and block cadence.

Ethereum / EVM family

Metrics such as finality, reorgs, and mempool behavior.

NEAR / PoS family

Metrics such as block production and validator health.

Other supported chains

A family-specific adapter that translates chain-native signals into the shared health model.
Chain-health integration follows the same incident and policy model. As adapters are rolled out, they can feed incidents through shared authorization and audit paths.

Incident API

SHIELD exposes two conceptual surfaces:

Status feed

A read path for consumers who need a summary of current incidents and degraded conditions.

Incident submission

A write path for authorized producers. Requests are authenticated and scope-checked before incident state is changed.
The public surface is intentionally narrow. Detailed schemas are shared through partner-facing reference materials, while this page explains the purpose of the system and the security model behind it.

Summary

SHIELD gives NEAR Intents a proactive way to raise security posture before an issue becomes system-wide damage. Today it combines shipped controls with an explicit roadmap:

Implemented controls

Incident management, scoped permissions, coarse security modes, and evaluate endpoints used by integrated consumers.

Scoped permissions

Explicit producer capabilities instead of inherited authority.

Coarse security modes

Simple postures that operators can apply quickly during an incident.

Roadmap-aligned vision

Progressive expansion from quote-centric safeguards toward broader, surface-specific response across the platform.