REST and gRPC

REST and gRPC are generated from the protobuf query and message services. This keeps the public contract typed, but it also means a client must use the schema that matches the target chain binary.

REST pattern

The standard Cosmos query routes use the cosmos namespace; RP1 modules use routes such as /rp1/<module>/v1/.... For example, MPP exposes parameter, charge, status, and payment-challenge queries through its generated HTTP annotations.

curl -fsS \
  "https://testnet.rest.rp.one/rp1/mpp/v1/params"

Do not copy a response shape from an older page into a client without checking the current proto message. Decimal amounts are strings, and pagination and custom integer fields need typed handling.

gRPC pattern

Use grpcurl or a generated client to inspect services and schemas. Transport security and listener ports are deployment-specific; do not assume that the public endpoint accepts plaintext gRPC on port 9090.

grpcurl -plaintext localhost:9090 list
grpcurl -plaintext localhost:9090 describe cosmos.bank.v1beta1.Query

For the public testnet, use the published gRPC endpoint and the transport settings supplied by its operator or provider. Keep TLS, authority, and port configuration in environment-specific settings rather than copying local plaintext flags into production.

Transaction submission

Cosmos transaction submission uses /cosmos/tx/v1beta1/txs or a module/client wrapper that signs and broadcasts a TxRaw. Choose the broadcast mode intentionally and always follow it with committed observation. A synchronous admission response is not a final execution receipt.

Schema discipline

• Generate clients from the target proto set.
• Preserve exact integer strings and byte encodings.
• Reject unknown or malformed addresses before signing.
• Bind a prepared message to the exact returned transaction bytes.
• Do not use a REST fallback to silently reinterpret an incompatible transaction.