Documentation

What Does the Documentation Cover?

The documentation layer is organized around the controls teams actually run: monitoring setup, integration configuration, alert routing, and the operational procedures that turn research into routine. Each guide starts from the problem a team is trying to solve — how to monitor a bridge route, how to wire a treasury alert lane, how to review a high-risk transaction — and walks through the setup against the policy the research hub explains.

This keeps the two layers distinct but connected. The research pages answer why a control matters and what failure it prevents; the documentation answers how to configure it in a running system. A team that wants to understand route risk scoring can read the framework, then use the documentation to wire the corresponding monitoring and alert lanes without re-deriving the design from scratch.

Getting Started

Register the protocol addresses, execution environments, and alert lanes you want Cyproli to monitor. Start with the riskiest production surfaces first so telemetry maps cleanly to live response priorities.

The SDK wraps the Cyproli API and provides typed helpers for the common operational patterns: pulling active threats, triggering incident playbooks, and managing alert routing. It handles authentication from environment variables so credentials never live in code or configuration files.

Configuration

Configure detection thresholds, response routing, and integration rules for Slack, PagerDuty, Telegram, and internal automation. Good configuration keeps noisy environments from overwhelming operators while preserving high-signal alerts for critical paths.

How Should Teams Structure Alert Routing?

Alert routing should follow severity and ownership rather than channel convenience. Critical execution signals go to the on-call pager; policy and configuration changes go to an audit log channel; informational signals go to a quieter lane that can be reviewed on a cadence. The point is to make sure that when an alert fires, the right person is reached with enough context to act — not that every alert reaches everyone.

Teams should treat routing as a configuration artifact with an owner, review it when the team or system changes, and record the routing decisions so an auditor can see why a given signal reached a given channel. This discipline is what turns a monitoring system from a source of noise into a control that actually shortens response time.

How Should Teams Prepare a New Environment?

Environment preparation is the step teams most often skip, and it is where integration mistakes are born. Before wiring any monitoring or alerting, define the environment scope: which contracts, routes, and signer sets belong to production versus staging, and which severity thresholds apply to each. A bridge route that should trigger a page in production may warrant only a quiet log in staging.

Use environment-scoped API keys so a misconfigured integration in staging cannot trigger production playbooks. Record the environment inventory in a single source of truth — a config file, a registry, or a documentation page — so the team knows what is being monitored and why. An environment that exists only in someone's memory is not a monitored environment; it is a gap waiting to become an incident.

What Should a Healthy Monitoring Baseline Look Like?

A healthy baseline means the team can answer three questions about every monitored surface: what normal looks like, what would indicate a problem, and who gets alerted when it happens. For a bridge route, normal might be a stable message rate and known validator set; a problem might be a validator set change or a sudden volume spike; the alert owner is the route operations team.

Baselines should be written down and revisited, because what is normal changes as the system evolves. The goal is not to eliminate every alert but to make each alert meaningful: it should name the surface, the signal, and the expected action. Alerts without that context train operators to ignore them, which defeats the entire monitoring investment.

How Do Integration Steps Map to the Research Controls?

Each integration guide in this documentation corresponds to a control described in the research hub. Setting up the /v1/threats/active polling for a treasury maps to the risk classification framework; wiring incident triggering for a bridge maps to the incident response guidance; configuring alert routing maps to the operational controls in the operational security cluster. This mapping is deliberate: the documentation does not invent new controls, it implements the ones the research layer already justifies.

How Does Documentation Keep Pace With the Research Layer?

Documentation is only useful when it reflects the current control model. As the research hub updates its guidance — for example, when a new route risk dimension is added or a containment procedure changes — the corresponding configuration and runbook pages are updated in the same cycle. Teams that deploy the SDK against the latest documentation get controls that match the policies the research layer actually recommends.