> ## Documentation Index
> Fetch the complete documentation index at: https://xoxno.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrating from the Go proxy

> Switch from the standard MultiversX Go proxy to the XOXNO Rust Gateway with minimal changes.

The XOXNO Gateway is a drop-in replacement for the standard MultiversX Go proxy. If your application already uses the Go proxy, switching requires only a base URL change.

## URL replacement

Change your base URL from your current Go proxy to the Rust Gateway:

```text theme={"system"}
https://rust-gateway.xoxno.com
```

All endpoint paths are identical. Endpoints are available under both `/v1.0/` and `/` (root) for full compatibility, so existing tools that use the `/v1.0/` prefix continue to work. Response JSON shapes match the Go proxy format, so you do not need to change client-side parsing.

You can test by pointing a staging environment to the Rust Gateway while keeping production on the Go proxy, then switch once you have validated compatibility.

## What stays the same

| Feature                 | Compatibility                                 |
| ----------------------- | --------------------------------------------- |
| Endpoint paths          | Identical                                     |
| Request/response format | JSON, same field names                        |
| Query parameters        | Same set (`onFinalBlock`, `blockNonce`, etc.) |
| HTTP methods            | Same per endpoint                             |
| Error response format   | Same `{"error": "..."}` structure             |
| Version prefix          | Both `/v1.0/` and `/` work                    |

## New capabilities

The Rust Gateway adds features beyond the Go proxy:

| Feature                 | Endpoint                         | Description                                                |
| ----------------------- | -------------------------------- | ---------------------------------------------------------- |
| Bulk account queries    | `POST /address/bulk`             | Query multiple addresses in one request, grouped by shard  |
| Storage key iteration   | `POST /address/iterate-keys`     | Paginated iteration over smart contract storage            |
| In-flight deduplication | Automatic                        | Identical concurrent requests share a single observer call |
| Prometheus metrics      | `GET /status/prometheus-metrics` | Native Prometheus scrape endpoint                          |

## Performance characteristics

* Built in Rust with Axum/Tokio for async I/O
* Near-zero heap allocations on the hot path
* Round-robin load balancing across observers with automatic failover
* TTL caching for block, hyperblock, heartbeat, validator stats, and economics endpoints
* Request coalescing prevents thundering herd on high-traffic endpoints

## Monitoring

| Endpoint                         | Format                     | Description                                                 |
| -------------------------------- | -------------------------- | ----------------------------------------------------------- |
| `GET /status/metrics`            | JSON (Go-proxy-compatible) | Per-endpoint request count, error count, and response times |
| `GET /status/prometheus-metrics` | Prometheus exposition      | Native scrape endpoint for Prometheus                       |
| `GET /about`                     | JSON                       | Proxy version and commit ID                                 |
| `GET /about/nodes-versions`      | JSON                       | Observer node software versions by shard                    |

The `/status/metrics` endpoint returns the same JSON structure as the Go proxy, so existing monitoring dashboards work without changes.

## Health checks

| Endpoint       | Purpose         | Behavior                               |
| -------------- | --------------- | -------------------------------------- |
| `GET /healthz` | Liveness probe  | Returns 200                            |
| `GET /readyz`  | Readiness probe | Returns 503 until observers are synced |

Use `/readyz` in your load balancer or Kubernetes health check configuration. The liveness probe confirms the process is running. The readiness probe confirms the Gateway can serve accurate data.