Interacting with gRPC
The Sentinel Hub runs a gRPC server alongside its RPC and LCD endpoints. Every module (the Cosmos SDK ones, IBC, CosmWasm and Sentinel's own) publishes a Protobuf query service on it, and the server answers reflection requests, so any gRPC client can discover the whole API without being given a schema file first.
The hub registers query services on its gRPC server. The MsgService definitions that describe transactions live in the same Protobuf files but are not served here: calling sentinel.node.v3.MsgService returns target server does not expose service. To change state you sign a transaction and hand the encoded bytes to cosmos.tx.v1beta1.Service/BroadcastTx. See Sending transactions.
Endpoints
The examples in these pages use fullgrpc-sentinel.busurnode.com:443. It and the one other public gRPC endpoint are listed under Endpoints; public gRPC is much thinner on the ground than RPC or REST, so verify one with grpcurl <endpoint> list before depending on it.
Public endpoints are served over TLS on port 443, so no -plaintext flag is needed. A node you run yourself serves plaintext gRPC on port 9090, which does need it. The examples set the address once so you can point them anywhere:
export GRPC=fullgrpc-sentinel.busurnode.com:443
The older grpc.sentinel.co:9090 address no longer accepts connections. Port 9090 is closed, and requests to grpc.sentinel.co are answered with an HTTP redirect that gRPC clients do not follow.
What the chain serves
Alongside the standard cosmos.*, ibc.* and cosmwasm.* services, the hub serves eleven Sentinel query services. Sentinel versions each module's service independently, so the version in the path is not the same across modules:
| Module | Current query service | Notes |
|---|---|---|
| node | sentinel.node.v3.QueryService | |
| plan | sentinel.plan.v3.QueryService | gRPC only, see below |
| provider | sentinel.provider.v3.QueryService | QueryParams only; providers are still read through sentinel.provider.v2 |
| session | sentinel.session.v3.QueryService | |
| subscription | sentinel.subscription.v3.QueryService | allocations are still read through sentinel.subscription.v2 |
| deposit | sentinel.deposit.v1.QueryService | |
| lease | sentinel.lease.v1.QueryService | added in hub v12 |
| oracle | sentinel.oracle.v1.QueryService | added in hub v12 |
| swap | sentinel.swap.v1.QueryService |
The sentinel.provider.v2 and sentinel.subscription.v2 services are still listed by reflection, but most of their methods now return Unimplemented. The gRPCurl page documents exactly which of them still answer, and lists every method of every service.
Hub v12 registers sentinel.plan.v3 and sentinel.provider.v3 on the gRPC server but not on the REST gateway. Their HTTP paths answer 501 Not Implemented, so these methods can only be reached over gRPC.
Enabling gRPC on your own node
gRPC is configured in ~/.sentinelhub/config/app.toml:
grpc.enable = true|false: whether the gRPC server runs at all. Defaults totrue.grpc.address = {string}: the address the server binds to. Defaults tolocalhost:9090, which only accepts connections from the machine itself. To reach it from anywhere else, set it to0.0.0.0:9090and put a TLS-terminating proxy in front of it.grpc.max-recv-msg-size/grpc.max-send-msg-size: message size limits. Raisemax-recv-msg-size(10 MB by default) if large paginated responses are being cut off.
