Assure
Assure is the operational layer that keeps the four Wallet Node layers (Validate, Execute, Observe, and Reconcile) running reliably. It applies to all of Wallet Node, and Nodit manages node operations, incident response, access control, and the support structure. This page describes how Wallet Node is operated and what level of assurance it provides.
- Availability
- Uptime SLA 99.9%
- Security certification
- SOC 2 Type I · Type II
- Operations
- 24/7 monitoring · incident response
- Audit logs
- API call history for the last 7 days
How Operations Work
Node requests in Wallet Node are processed through HyperNode. HyperNode is a routing layer in front of the node pool, and it decides which node receives each request based on the node's synchronization status, latency, and availability. Adding more nodes alone cannot resolve the differences in response speed, block height, and failures between nodes, so this decision is made at the routing stage.
- Node health monitoring: Evaluates the synchronization status, latency, and availability of all nodes in real time.
- Node routing: Sends requests to a node that is synchronized to the latest block and can process them.
- Automatic failover: Removes unhealthy nodes from traffic and automatically switches requests to healthy nodes.
- Rejoin after verification: Returns a recovered node to traffic only after verifying its status and synchronization.
Nodit also handles node operations. Customers can integrate through the API without building node infrastructure or staffing operations teams.
| Operational task | Details |
|---|---|
| Security patches and client upgrades | Applies security patches and version upgrades to node clients |
| Hard fork handling | Updates nodes for network hard forks |
| Monitoring and incident response | Monitors nodes with a cluster-based monitoring system and responds when incidents occur |
Service Levels
The node infrastructure that runs Wallet Node can be configured as Elastic Node, a shared node cluster, or Dedicated Cluster, an isolated environment dedicated to the customer. The configuration, SLA figures, and contract terms are finalized per institution during the onboarding consultation.
| Item | Elastic Node | Dedicated Cluster |
|---|---|---|
| Availability (SLA) | 99.9% | 99.9% or higher, contract-based |
| Infrastructure | Shared node cluster | Isolated environment with resources allocated exclusively to the customer |
| Throughput | Request limits per plan · Auto-scaling during peak hours | Designed for your workload, with capacity expansion available on request during operation |
| Incident response and support | Status page · public channels | Communication through a dedicated contact channel |
In addition to the items above, Dedicated Cluster provides the following.
- Infrastructure in a Korean data center: Runs on low-latency infrastructure in a Korean data center, and sets up dedicated connectivity that meets the customer's network requirements.
- Node monitoring dashboard: View node status, request volume, throughput, and latency on a single dashboard.
- 24/7 dedicated support: Receive technical support and incident response through a dedicated channel.
- Reorg-aware RPC handling: On supported networks, HyperNode detects chain reorganizations (reorg) and refreshes cached RPC data.
Dedicated Cluster is adopted in this order: requirements discussion → infrastructure design and quote → provisioning and migration → operations and ongoing support. During the design stage, node specifications are sized based on the number of networks, concurrent requests, and data retention period. See Dedicated Cluster for the adoption process.
Security and Access Control
The Nodit infrastructure that runs Wallet Node operates under a control framework audited for SOC 2 Type I and Type II. Customers can configure access control and the audit environment directly in the console, and the security settings you configure stay in place when you scale the service or move to Dedicated Cluster.
| Item | Details |
|---|---|
| Access control | Restricts API call origins by Source IP and Domain Name. Requests from origins not on the Allowlist are blocked with HTTP 403. See Security for setup |
| Permission management (RBAC) | Separates the Team Owner and Team Member roles in a team account to manage permissions for project resources such as API Key, Webhook, and Request Logs. See Team Account for setup |
| Request logs | View API call history and responses for the last 7 days in the console. Filter by network, period, HTTP Status, and Error Code for incident analysis and audit evidence. See Request Logs for usage |
| Webhook message verification | Verify the origin and integrity of Webhook messages with the Signing Key when you receive them |
Monitoring and Support
You can check service status in real time on the Status page, and integrate it with your own monitoring systems. Nodit monitors the infrastructure 24/7 and supports inquiries and incident response through a dedicated operations team channel.
| Item | Details |
|---|---|
| Public operating status | Publishes service operating status in real time on the Status page |
| Usage monitoring | View CU-based usage in real time in the console |
| Event delivery recovery | If Webhook delivery fails, automatic retry (Retry/Backoff) is applied. Check failure history in Delivery History, and resend with Easy Resend |
| Contact channels | Contact us by email at [email protected] or through the Nodit contact page |
Customer Responsibilities
Assure guarantees availability and operational quality for the parts that Nodit operates. For the integration points with the customer's systems, the customer must verify and manage the following items.
| Item | What the customer verifies and manages |
|---|---|
| Access control settings | Store API Keys securely and configure the IP and Domain Allowlist for your operating environment |
| Webhook receipt verification | Verify the origin and integrity of messages with the Signing Key. This is required when integrating with external endpoints |
| Data reflection timing | The time it takes for an on-chain event to appear in indexed data can differ by chain and network. Measure it with real transactions to confirm it meets your service requirements |
| Request limits | Compare the request limits of your plan with your actual call patterns to check for bottlenecks. See Rate Limits for the limits per plan |
| Connection recovery | Implement reconnection logic in your systems for when a WebSocket connection drops, and check for missed data at the time of reconnection |