POLYMER / The Verifiable RPC Network

Verifying the
Onchain Economy.

Every wallet, bridge, and exchange reads the blockchain through someone else's server, and trusts whatever it says. Polymer signs every provably correct response inside tamper-proof hardware.

Read the whitepaper

01 // PROTOCOL ARCHITECTURE

Security Properties

Hardware

Intel TDX · sealed section of the chip

Software

locked · measured at startup

any tampering is detectable

Signing key

lives inside only · never exposed

POLYMER VERIFIABLE NODE · INTEL TDX

BLOCKCHAIN READER

reads full chain data

fetches the real answer

RESPONSE PACKER

packages the answer

ready for signing

SIGNING KEY

Private key

never leaves the hardware

HARDWARE-LOCKED

HARDWARE PROOF

confirms enclave is live

attached to every response

IDENTITY LOCK

ties key to this software

can't be swapped or faked

software verified · tamper-evident · Polymer v2

Every response is signed, secured, and verifiable

02 // THE PROBLEM

Your app doesn't read the blockchain. A server does.

Every wallet, bridge, and exchange gets blockchain data through a server someone else controls. Encrypting the connection doesn't verify the answer — it just means no one intercepted it. If the server itself lies, the lie is indistinguishable from the truth.

YOUR APP

wallet · bridge · exchange

asks for on-chain data

trusts whatever it receives

UNVERIFIABLE SERVER

someone else's machine

could return anything

! no verification possible

reads from

THE BLOCKCHAIN

the actual truth

immutable · public

CRITICAL Kelp DAO · LayerZero bridge April 18, 2026 attribution: Lazarus Group (DPRK)

// What happened · April 18, 2026

HONEST NODE

canonical RPC node

serving correct data

status: DDoS'd offline

→ REPLACED BY

POISONED NODE

swapped by attacker

same address · different software

behavior: selective lie

// TO EVERYONE ELSE

returned correct data — no alerts triggered

// TO LAYERZERO'S VERIFIER

returned forged data — bridge accepted it

// WITH POLYMER — THIS ATTACK FAILS

A swapped binary produces a different hardware fingerprint. The public registry rejects the node. It can't produce a valid signature. The attack has nowhere to go.

Drained in a single exploit

$292M

Bridge withdrawal · LayerZero rsETH

116,500 rsETH · ~18% of circulating supply.

// 47 minutes · 0 alerts

T − 5m

DDoS honest nodes offline

T + 0

Binary swapped on two RPC nodes

T + 19m

Forged answer sent to verifier

T + 47m

Bridge drained — $292M

"More verifiers don't help when every verifier is reading from the same opaque RPC layer."

03 // THE SOLUTION

Polymer seals the server inside tamper-proof hardware.

The problem isn't that a server reads the blockchain — it's that you can't verify what it's doing. Polymer locks the node inside a hardware enclave: a sealed environment where the software is fixed, the signing key never leaves, and every answer carries proof it came from the right place.

WITHOUT POLYMER

YOUR APP

request

UNVERIFIED SERVER operator controls it — can return anything

answer

RESPONSE no signature · no proof

✗ No way to verify it's true

If the binary is swapped — nothing changes. Old signatures still valid. Attack undetectable.

WITH POLYMER

YOUR APP

request

HARDWARE ENCLAVE

SEALED NODE software locked · signing key never leaves

signed answer

RESPONSE + SIGNATURE signed by a key that never left the hardware

✓ Signature verified — answer trusted

If the binary is swapped — new image digest, registration rejected, old key is gone. Attack has nowhere to go.

The operator can slow or stop the server. They cannot change what it says.

04 // REQUEST FLOW

From request to verified answer.

Your app asks for blockchain data. The node answers from inside sealed hardware, signs the response, and sends back proof of where it came from. Your app checks the signature — and knows the answer is real.

How a request gets answered and verified ━━ request ━━ signed response ┄┄ verification

// YOUR APP

YOUR APP

wallet · bridge · exchange

requests blockchain data

asks for on-chain data

SERVER · OPERATOR-CONTROLLED

SEALED HARDWARE ENCLAVE code verified ✓

Reads from the blockchain

fetches the answer and packages it for signing

SIGNING KEY

Private key

locked inside hardware — never leaves

HARDWARE PROOF

Live attestation

confirms the enclave is active and unmodified

operator can turn it on or off — cannot change what it says

signed answer + hardware proof

// ON-CHAIN

ON-CHAIN

Public Registry

list of approved nodes and their signing keys

managed by governance · publicly auditable

05 // TRUST PILLARS

Three pillars. Hardware. Cryptography. Public verifiability.

Hardware locks the node down. Cryptography signs every response. Open source lets anyone audit what's actually running. Three independent checks behind every read.

Hardware

Intel TDX · silicon enclave

The node runs inside a sealed compartment built into the chip. The server operator can turn the machine on — but they can't see or change what's running inside. The hardware itself enforces this.

GUARANTEES The software inside is exactly what was approved — nothing else can run

→

Cryptography

Per-node key · ECDSA secp256k1

Every answer the node sends is signed with a key that was created inside the enclave and has never left. You can verify the signature yourself. If the answer was tampered with — or came from a different machine — the signature won't match.

GUARANTEES Every response is signed — a bad answer can't forge a valid signature

→

Public verifiability

Reproducible builds · open source

The node's code is public. Anyone can download it, compile it, and check that it produces the same binary that's registered on chain. You don't have to trust Polymer's word — you can verify it yourself.

GUARANTEES The code running on chain is the same code anyone can read and audit

→ THE RESULT

Signature checks out · key is registered · code matches public source · answer is trusted

VERIFIED

06 // WHO IT'S FOR

Any app that reads the blockchain inherits the risk.

The attack surface isn't a single protocol — it's every application that trusts an RPC response. The window to address it is closing.

BRIDGES · DVNs

Cross-chain messaging

A poisoned RPC poisons the attestation. With Polymer, a swapped binary can't register — poisoned failovers have nowhere to land.

EXCHANGES · CUSTODIANS

Deposits & withdrawals

A signed response is an audit-grade receipt of the exact state acted on — useful for internal forensics and regulators.

WALLETS · APPS

Balances & approvals

Point at a Polymer endpoint, add the verifier library. Balances, quotes, and gas estimates become signature-checked end-to-end.

ORACLES · INDEXERS

Upstream data integrity

An oracle reading from a poisoned RPC poisons every protocol downstream. Polymer closes the upstream gap without replacing your attestation scheme.

// HOW WE COMPARE

	Infura / Alchemy	Pocket	Lava	1RPC	Polymer
Response integrity	✗	✗	~	✗	✓
Binary swap detectable	✗	✗	✗	✗	✓
Hardware-attested node	✗	✗	✗	~	✓
Selective-lie resistant	✗	✗	✗	✗	✓
Permissionless operators	✗	✓	✓	✗	✓

~ Lava uses VRF sampling — defeated by selectively lying to non-samplers (the Kelp pattern). 1RPC attests requests for privacy, not responses for integrity.