Polygon gRPC API
GetBlock provides fast and reliable access to Polygon nodes via gRPC API. Connect to the Polygon network without running your own infrastructure.
Polygon gRPC is the binary Protocol Buffers interface exposed by Bor v2.8.3+ for high-performance consensus-layer coordination with Heimdall v2. It is not a replacement for Bor's Ethereum JSON-RPC — the eth_* execution surface remains the primary developer interface for smart contracts, transactions, and account state.
What Bor gRPC provides is a strongly typed, HTTP/2 Multiplexed transport for the specific set of calls that Heimdall v2 makes against Bor to build checkpoints, propose milestones, verify block producers, and correlate spans. Because it uses Protocol Buffers instead of JSON-RPC, milestone proposition — the single hottest path in the Heimdall→Bor interaction — runs approximately 4.4× faster than the equivalent HTTP JSON-RPC round trip (per Polygon Labs' devnet benchmarks).
The service is defined at https://github.com/0xPolygon/polyproto/tree/main/bor and exposes a single gRPC service — bor.BorApi — with 11 unary methods. There are no streaming endpoints and no bidirectional calls; every method is a request/response pair. Bor v2.8.3 introduces the server implementation (disabled by default, loopback bind on activation, PR #2194); Heimdall v2 v0.9.0 introduces the client side (opt-in via bor_grpc_flag = "true" in app.toml). HTTP JSON-RPC remains the default transport for backward compatibility.
Key Features
Single Service, 11 Methods:
bor.BorApi— no service sprawl, no versioned aliases, no deprecated legacy names. Every method has a purpose in the Heimdall↔Bor coordination pathProtocol Buffers Over HTTP/2: strongly-typed schemas via the polyproto
.protofiles; binary encoding produces ~3-5× smaller payloads than JSON-RPC and enables HTTP/2 multiplexingBatched Block Info in One Round Trip:
GetBlockInfoInBatchreturns headers + total difficulty + author addresses for[startBlockNumber, endBlockNumber]— replacing what used to require N separate JSON-RPC calls per block with a single gRPC callNative Bor System Receipts:
BorBlockReceiptexposes the sprint-boundary state-sync transaction receipts that Bor generates internally — a Bor-native concept with no direct Ethereum equivalent, essential for bridge indexers tracking Ethereum → Polygon state sync flowConsensus-Grade Root Hashes:
GetRootHash(startBlock, endBlock)computes the Merkle root over a Bor block range in the exact form Heimdall uses to build checkpoint submissions to Ethereum L1Milestone Voting Support:
GetVoteOnHashaccepts a milestone ID and hash, and returns whether the local Bor node accepts the milestone proposal — the primary voting input for validator milestone acknowledgmentBearer Token Authentication: gRPC metadata carries an authorization token. Loopback deployments can leave it empty (Bor's
[grpc]section defaults to loopback bind); public exposure requires the token to be setZero Impact on Ethereum JSON-RPC: gRPC and JSON-RPC coexist on the same Bor node. Enabling gRPC doesn't change
eth_*method behavior. Applications using Bor for standard EVM reads/writes need not migrate
TECHNICAL DISCLAIMER: AUTHORITATIVE BOR GRPC SPECIFICATION
GetBlock's Polygon Bor gRPC API reference documentation is provided exclusively for informational purposes and to optimize the developer experience. The canonical and normative specifications for the bor.BorApi service — including exact protobuf message schemas, field ordering, and the shared common.H160 / common.H256 type definitions — are maintained by:
Polygon: github.com/0xPolygon/polyproto — the
.protofiles are the source of truth.bor/bor.protodefines this service;common/common.protodefines sharedH160(20-byte address) andH256(32-byte hash) typesBor: github.com/0xPolygon/bor — the reference server implementation (see PR #2194 and the
internal/cli/server/api_service.gofile for the Go-side implementation)Heimdall v2: github.com/0xPolygon/heimdall-v2 — the reference client, and the primary consumer for which this API was designed
Network Information
Service
bor.BorApi
Proto Package Path
bor (defined in polyproto/bor/bor.proto)
Total Methods
11 (all unary — no streaming)
Common Types
common.H160 (20-byte address), common.H256 (32-byte hash)
Protocol
Protocol Buffers over HTTP/2 (TLS on public endpoints)
Authentication
Bearer token in gRPC metadata (authorization: Bearer <TOKEN>)
Default Self-Hosted Port
3131 (loopback bind by default in Bor v2.8.3+)
Server Version Required
Bor v2.8.3 or newer
Reference Client Version
Heimdall v2 v0.9.0 or newer
Bor Config Section
[grpc] in config.toml — addr = "127.0.0.1:3131", token = ""
Server Reflection
Depends on Bor build (verify with grpcurl list against production endpoint)
Bor Chain ID (Mainnet)
137
Base URL
Polygon Bor gRPC is exposed on GetBlock's standard TLS endpoint pattern — the same pattern used by TRON gRPC and Solana Yellowstone gRPC. Select the region closest to your consumer when creating the endpoint in the GetBlock dashboard.
Supported Networks
Polygon PoS Mainnet (Bor 137)
✅
✅
✅
✅
Quickstart
In this section, you will learn how to fetch the latest Bor block header — the most recently produced block on Polygon PoS — using either:
grpcurl(CLI — the universal gRPC probe tool)JavaScript (Node.js with
@grpc/grpc-js)Python (with
grpcio)
HeaderByNumber is a good first call because it uses the same "block number or tag" convention ("latest", "earliest", "pending", "finalized", "safe", or hex "0x...") as standard Ethereum JSON-RPC, so its input semantics are immediately familiar. Its response validates two things at once: your gRPC connection works, and the response schema matches the polyproto/bor/bor.proto Header message.
Available API Methods
bor.BorApi exposes 11 unary methods. Organized by function:
Chain State Reads (3 methods)
HeaderByNumber
Returns a block header for a given block number or tag
BlockByNumber
Returns a block (currently header-only per the schema) for a given number
GetAuthor
Returns the block producer (author) address for a given block number
Receipt Reads (2 methods)
TransactionReceipt
Returns the receipt for a transaction hash
BorBlockReceipt
Returns the Bor system-level block receipt (state-sync transactions at sprint boundaries)
Fork-Choice Data (2 methods)
GetTdByHash
Returns total difficulty by block hash
GetTdByNumber
Returns total difficulty by block number or tag
Consensus Operations (2 methods)
GetRootHash
Computes the Merkle root of a Bor block range for checkpoint construction
GetVoteOnHash
Returns whether the local node accepts a milestone proposal for a block range
Span Correlation (2 methods)
GetStartBlockHeimdallSpanID
Maps a Bor start block to its corresponding Heimdall span ID
GetBlockInfoInBatch
Returns headers + total difficulty + author for a block range in one call — the ~4.4× milestone proposition speedup
Support
For technical support and questions:
Support Email: support@getblock.io
See Also
polyproto GitHub — the source of truth for
bor.BorApiand common typesbor/bor.proto— thebor.BorApiservice definitioncommon/common.proto— theH160andH256message types used throughoutBor v2.8.3 Release Notes — server implementation (PR #2194)
Polygon JSON-RPC — the standard EVM
eth_*interface (separate from this gRPC service)grpcurl Documentation — universal gRPC exploration tool used in the Quickstart
Last updated
Was this helpful?