Integration and monitoring
Read protocol state, submit authorized actions, and track obligations through final resolution.
Contracts record the authoritative state
Each Business Validator write is a contract action for one role. An authorized operator signs it, or a caller submits it through a permitted public entry point. The indexed API and the dashboard make these records easier to inspect. They do not replace the contract's authorization checks.
After a write, inspect the receipt and the resulting state. How transactions settle explains why the dashboard can lag behind.
Start with the testnet tools
- Dashboard: your institution's workspace (Home, Tasks, Risk, Activity, All actions) and one set of tabs per role. The administration views need a wallet with the BV administration permission.
- Block explorer: inspect transactions, logs, and deployed contracts.
- Network metadata: inspect the API's environment metadata.
- Endpoint directory: find the REST API and application event WebSocket.
Confirm the chain and release before you sign. A wallet connection and an API response do not prove that a BVID (Business Validator identity) is admitted, or that a role can accept new volume.
Monitor obligations, not just balances
| Area | Information to track |
|---|---|
| Identity | Current operator, roles, and BVID status |
| Collateral | Posted and withdrawable stake, reservations, health, price freshness |
| Asset service | Metadata events, re-attestations, scoring coverage, and liability portfolios |
| Scoring | Publication cadence, scoring windows ready for evaluation, and completed evaluation results |
| Insurance | Policy ownership, expiry, claim state, and full-payment status |
| Enforcement | Provisional penalties, dispute deadlines, and final outcomes |
| Exit and rewards | Auction progress, remaining obligations, finalized epochs, and claims |
The protocol read API covers validators, assets, policies, claims, obligations, calibrations, disputes, reward epochs, auctions, and events. It also has routes for T-REX suites, an overview, operator portfolios, and migrations.
Keepers provide progress
Many checks need someone to send a transaction after a deadline. Keepers are services that watch for these conditions and submit the calls. The contracts then verify each call. Keepers move the protocol forward. A deadline passing does not by itself run a transaction.
Keeper calls are different from privileged inputs. Payment reporting and price updates come from authorized sources. If you call all off-chain services trustless, you hide these dependencies.
Handle delayed and repeated observations
The indexer follows canonical blocks. When it detects a reorganization, it rebuilds its projections. The application WebSocket delivers events, but it is not the chain's Ethereum subscription endpoint.
After a reconnect, reconcile against current state. Do not treat repeated events as new obligations. Record transaction and case identifiers in your operations system. Make each alert point to a specific payment, penalty, dispute, or auction that an operator can inspect and act on.