Polygon private transactions

Public Polygon transactions are normally broadcast to a public RPC endpoint and propagated through the peer-to-peer network. This can expose the signed transaction before it is included in a block.

Hyperstrate uses a different delivery path. It validates the signed transaction and sends it only to qualified private targets configured for the selected Polygon chain.

The private transaction flow

1. Your application builds a Polygon transaction.
2. Your wallet or signing service signs it locally.
3. Your application submits the serialized transaction to Hyperstrate.
4. Hyperstrate validates the signature, chain ID, transaction format, and basic fee constraints.
5. The payload is encrypted at rest and queued for durable delivery.
6. Hyperstrate sends it to qualified private producer infrastructure.
7. Hyperstrate monitors the chain for inclusion and updates the transaction status.

Hyperstrate does not need access to your private keys at any point in this process.

Ethereum JSON-RPC compatibility

Hyperstrate provides a standards-compatible submission endpoint at:

POST /polygon/rpc

It uses JSON-RPC 2.0 and supports these Polygon/Ethereum methods:

eth_sendRawTransaction returns the standard 0x-prefixed Polygon transaction hash. Internally, the signed payload still passes through Hyperstrate validation, durable intake, billing, and private routing.

Privacy guarantees

When Polygon private delivery is enabled:

• Hyperstrate does not broadcast the transaction through a public RPC endpoint.
• The signed payload is encrypted while stored by Hyperstrate.
• Payloads are sent only to qualified targets configured for the matching chain.
• A failed private route does not silently fall back to public broadcasting.
• Delivery records identify targets without exposing their credentials.

What private delivery does not guarantee

Private delivery reduces public mempool exposure, but it is not an absolute confidentiality guarantee.

• Participating producer infrastructure must receive the signed transaction to process it.
• The transaction becomes public when it is included on-chain.
• Private delivery does not guarantee inclusion or successful execution.
• Contract execution can still revert.
• A transaction already dispatched to a producer may still land after a stop request.
• Hyperstrate does not manage your nonce, gas strategy, wallet, or signing keys.

Discover the active network

Do not assume a chain ID or submission format. Read the current network configuration before constructing a transaction:

curl --request GET \
  --url "https://app.hyperstrate.xyz/api/v1/networks"

An enabled Polygon network resembles:

[
  {
    "namespace": "polygon",
    "chainId": 137,
    "private": true,
    "product": "polygon-private-tx",
    "capabilities": {
      "submissionFormat": "evm-signed-hex",
      "observe": true,
      "stop": true,
      "replace": true
    },
    "availability": {
      "accepting": true,
      "observing": true
    }
  }
]

Before submitting, verify:

• namespace is polygon
• private is true
• availability.accepting is true
• The signed transaction uses the returned chainId
• The request uses the returned submissionFormat

Transaction lifecycle

For more detail, inspect deliveryState, executionState, and billingState in the transaction response.

Submission interfaces

For EVM tooling and standard RPC integrations, submit the signed transaction with eth_sendRawTransaction:

{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransaction",
  "params": ["0xSIGNED_TRANSACTION_HEX"],
  "id": 1
}

Both submission interfaces use the same Hyperstrate pipeline: validation, durable intake, billing, encrypted storage, private delivery, and status tracking. Choose the interface based on the response your integration needs:

• JSON-RPC returns the standard Polygon transaction hash.
• REST returns the Hyperstrate submission record, including its native ID and current lifecycle states.

To receive the Hyperstrate submission record at submission time, send the following body to POST /polygon/v1/transactions:

{
  "format": "evm-signed-hex",
  "payload": "0xSIGNED_TRANSACTION_HEX"
}

The payload must be:

• A serialized, signed EVM transaction
• Signed for the configured numeric chain ID
• Recoverable to a valid sender
• Configured with a nonzero gas limit
• No larger than 128 KiB
• Encoded as hexadecimal, with or without the 0x prefix