# gRPC

Access gRPC-based blockchain nodes through a single endpoint. Authentication and chain routing travel in gRPC metadata, so one connection reaches every gRPC chain.

`grpc.vilna.io:443`
gRPC over TLS
Tron
`x-api-key` metadata

## Connection 

```
grpc.vilna.io:443
```

TLS is required. Authentication and chain identification are passed as gRPC metadata:

| Metadata key | Value |
|  --- | --- |
| `x-api-key` | Your RPC key |
| `x-chain-id` | RPC routing identifier or alias (for Tron, `tron:mainnet` or `tron`) |


For Tron, use a CAIP-2 ID or alias from the [network table](/apis/networks#table): for example, `tron:728126428` or `tron` for Mainnet, and `tron:3448148188` or `tron-testnet` for Nile. `tron:mainnet` and `tron:testnet` are also supported. Solana uses [JSON-RPC](/apis/rpc/json-rpc).

Always specify the port
Include the `:443` port explicitly. Some clients (including `grpcurl`) don't assume a default and fail with `missing port in address` when it's omitted.

## Tron 

Vilna forwards gRPC requests transparently to the Tron node. Available methods depend on that node. The `grpcurl` examples below require node-side gRPC reflection; if it is unavailable, supply the official [Tron protobuf definitions](https://github.com/tronprotocol/protocol) to `grpcurl` with `-import-path` and `-proto`.

Current block

GetNowBlock2

protocol.Wallet

```bash
grpcurl \
  -H "x-api-key: your-api-key" \
  -H "x-chain-id: tron:mainnet" \
  -d '{}' \
  grpc.vilna.io:443 \
  protocol.Wallet/GetNowBlock2
```

Sanity check

TotalTransaction

protocol.Wallet

```bash
grpcurl \
  -H "x-api-key: your-api-key" \
  -H "x-chain-id: tron:mainnet" \
  grpc.vilna.io:443 \
  protocol.Wallet/TotalTransaction
```

Block by number

GetBlockByNum2

protocol.Wallet

```bash
grpcurl \
  -H "x-api-key: your-api-key" \
  -H "x-chain-id: tron:mainnet" \
  -d '{"num":70000000}' \
  grpc.vilna.io:443 \
  protocol.Wallet/GetBlockByNum2
```

No `grpcurl` installed? The same call runs from Docker:

```bash
docker run --rm fullstorydev/grpcurl \
  -H "x-api-key: your-api-key" \
  -H "x-chain-id: tron:mainnet" \
  -d '{}' \
  grpc.vilna.io:443 \
  protocol.Wallet/GetNowBlock2
```

### Available services

Standard Tron gRPC services include:

| Service | Description |
|  --- | --- |
| `protocol.Wallet` | Account, transaction and block operations |
| `protocol.WalletSolidity` | Read-only queries against confirmed blocks |
| `protocol.Database` | Low-level chain data access |


For the full method list, see the [Tron protocol documentation](https://developers.tron.network/reference).

## Error handling 

For an uncertain transaction broadcast, follow the [recovery steps before retrying](/apis/rpc#retries).

Authentication failures return native gRPC statuses:

| Situation | gRPC status |
|  --- | --- |
| Missing, ambiguous or invalid API key | `UNAUTHENTICATED` |
| Wrong key type or insufficient permission | `PERMISSION_DENIED` |
| Authentication service unavailable | `UNAVAILABLE` |


Routing and proxy failures can arrive as HTTP responses without a native `grpc-status`:

| Situation | HTTP status |
|  --- | --- |
| Missing `x-chain-id` | `400` |
| Unknown network or a network without a gRPC route | `404` |
| Request rate limit exceeded | `429` |
| Connection failure, unavailable node or timeout | `502`, `503` or `504` |


Your client may translate these HTTP failures into gRPC errors. Do not rely on `NOT_FOUND` or `INVALID_ARGUMENT` for routing failures. Errors returned by the node retain its native gRPC status. See [Errors](/apis/errors).