LP Risk Radar
PulseChain
pDAI
ON-CHAIN LIQUIDITY TRANSPARENCY · built for PulseChain

The LP
Risk Radar

Before you add liquidity, see what you're standing on. Every number pulled from the chain — three times.

A read-only x-ray of PulseChain liquidity pools. It shows you the reserves, the burned LP, the control surface and the fork-mirror reality behind a pool — as verifiable facts, never buy signals. You decide. The chain does the talking.

RPC verify
0
Buy signals
1
Pool live (demo)
Why this exists

Most people add liquidity blind. The pool was never hiding anything.

Providing liquidity is where regular holders get hurt the most — not because the risk was hidden, but because nobody reads it. You ape into a pool because a chart looked green or a Telegram voice said “good yield,” and you never checked the one thing that actually decides your outcome: what is inside the pool, who controls it, and how much of the liquidity can walk away. Every one of those answers is sitting on-chain right now — public, permanent, and queryable by anyone. The LP Risk Radar reads it for you and puts it on one card.

This is the defensive twin of the On-Chain Analyst's Path. The Path teaches you to read the chain yourself; the Radar reads it for you at the single moment most retail positions blow up — the decision to provide liquidity. Same discipline, same rule: a number is not a fact until three independent RPCs agree on it. Every figure on this page carries its ✓ 3/3 verdict, and the exact command that produced it is printed below so you can re-run it and get the same answer.

One line we will never cross: the Radar states facts, it does not give advice. It will not tell you to add, pull, or leave. That is your call, and a good tool respects that it is your money and your judgment. What it refuses to do is dress a fork-mirror asset up as real value, or hand you a buy signal with a confident face. It shows you the ground. Where you step is up to you.

Who this is for

For the PulseChain holder who is about to add liquidity to a pDAI pool and wants to know what they are actually walking into — before the transaction, not after the loss. You do not need to be a developer or read Solidity. You need the pool's real reserves, its burned-LP share, its control surface, and an honest note on what part of that we cannot prove from the chain alone. That is this page.

01
Pool x-ray

pDAI / ATROPA — read straight off the chain

Not a claim, not a screenshot — the pool's own storage, confirmed by three independent PulseChain RPCs at the same block.

Snapshot 2026-07-13 · verified 3/3 · rpc.pulsechain.com · pulsechain-rpc.publicnode.com · rpc-pulsechain.g4mm4.io
Example: pDAI / ATROPA · 5EF7
pDAI / ATROPA PulseX V2 pair ✓ immutable · no admin key
Pair 0x5ef7aac0de4f2012cb36730da140025b113fada4
token0 pDAI 0x6B175474E89094C44Da98b954EedeAC495271d0F · symbol “DAI” · 18 dec
token1 ATROPA 0xCc78A0acDF847A2C1714D2A925bB4477df5d48a6 · symbol “ATROPA” · 18 dec
Factory 0x1715a3E4A142d8b698131108995174F37aEBA10D · PulseX
Reserve · pDAI
5,294,671,392.80
raw 5294671392802616018661601873 (÷1e18)
✓ 3/3 RPC · getReserves()
Reserve · ATROPA
260,575,103.94
raw 260575103940168513114980688 (÷1e18)
✓ 3/3 RPC · getReserves()
LP total supply
1,172,639,921.71
raw 1172639921712426714102713032 (÷1e18)
✓ 3/3 RPC · totalSupply()
LP burned to 0x…dEaD
93.80%
1,100,000,000 LP locked forever — cannot be withdrawn by anyone
✓ 3/3 RPC · balanceOf(0xdEaD)
LP live / pull-able
6.19%
≈ 72,639,921.71 LP held by live wallets who can add or remove at will
✓ derived from verified reads
Control surface
No admin
owner() reverts on all 3 RPCs — standard immutable V2 pair, no key can drain it
✓ 3/3 RPC · owner() → revert
Neutral read 93.80% of this pool's liquidity is burned to the dead address — permanently locked, un-ruggable. The remaining 6.19% sits with live holders. The pair has no owner or admin function, so no key can drain it; liquidity only leaves when a holder burns their own share. What the Radar will not pretend: the pDAI side is forked DAI. Per the Analyst's Path, a forked-token figure is not real value at face — 5.29 billion pDAI here is depth in a fork-mirror asset, not 5.29 billion dollars. The Radar shows the pool's structure; it does not endorse the token's worth, and it does not tell you to add, pull, or leave.
369
On PulseChain. pDAI lives at the same address as Ethereum's DAI (0x6B175474E89094C44Da98b954EedeAC495271d0F) because PulseChain forked Ethereum's entire state in May 2023. Same address, different chain, different reality — which is exactly why every read on this page is run against PulseChain RPCs, never an Ethereum endpoint. A number from the wrong chain is worse than no number.
02
Verification ledger

Keep the receipts — re-run every number yourself

If you can't reproduce it, it isn't on the card. Here is the exact terminal transcript behind every figure above.

tv.sh — triple-verify, 3 independent PulseChain RPCs
# Each read is run against 3 independent RPCs; a value is only released on ✅ TRIPLE-MATCH.
# rpc.pulsechain.com · pulsechain-rpc.publicnode.com · rpc-pulsechain.g4mm4.io

tv.sh 0x5ef7aac0de4f2012cb36730da140025b113fada4 "token0()(address)"
# ✅ 0x6B175474E89094C44Da98b954EedeAC495271d0F      -> pDAI

tv.sh 0x5ef7aac0de4f2012cb36730da140025b113fada4 "token1()(address)"
# ✅ 0xCc78A0acDF847A2C1714D2A925bB4477df5d48a6      -> ATROPA

tv.sh 0x5ef7aac0de4f2012cb36730da140025b113fada4 "factory()(address)"
# ✅ 0x1715a3E4A142d8b698131108995174F37aEBA10D      -> PulseX factory

tv.sh 0x5ef7aac0de4f2012cb36730da140025b113fada4 "getReserves()(uint112,uint112,uint32)"
# ✅ 5294671392802616018661601873 | 260575103940168513114980688 | 1783912495
#    reserve0 = 5,294,671,392.80 pDAI   reserve1 = 260,575,103.94 ATROPA   ts = 2026-07-13

tv.sh 0x5ef7aac0de4f2012cb36730da140025b113fada4 "totalSupply()(uint256)"
# ✅ 1172639921712426714102713032       -> 1,172,639,921.71 LP

tv.sh 0x5ef7aac0de4f2012cb36730da140025b113fada4 "balanceOf(address)(uint256)" 0x000000000000000000000000000000000000dEaD
# ✅ 1100000000000000000000000000        -> 1,100,000,000 LP burned = 93.80%

tv.sh 0x5ef7aac0de4f2012cb36730da140025b113fada4 "balanceOf(address)(uint256)" 0x0000000000000000000000000000000000000000
# ✅ 1000                                -> min-liquidity lock (Uniswap V2 MINIMUM_LIQUIDITY)

tv.sh 0x5ef7aac0de4f2012cb36730da140025b113fada4 "owner()(address)"
# ✅ REVERT (3/3 consistent)             -> no owner/admin function exists

Every value on the pool card traces to one line here. tv.sh fires the same read at three independent PulseChain RPCs and only prints a value when all three agree — a mismatch is treated as no answer, not a best guess. Copy any line, run it, and you get the same number, because it is the pool's own storage, not our claim about it.

result8 reads, 8× TRIPLE-MATCH. Zero single-source figures on this card.
AI
The AI flow. An AI can draft these calls, label the tokens, and turn raw wei into human numbers in a second — but it never sourced a single figure above. The chain did, three times. That split — AI writes and interprets, the chain and the tool attest — is the whole reason you can trust this page instead of taking our word for it.
03
What we can prove

Honest edges — what the chain answers, and what it doesn't

A transparency tool that hides its own blind spots is just another rumor. Here is exactly what is triple-verifiable and what is not.

The feasibility spike found a clean split, and it happens to point the same way the product does. The structural, safety-relevant facts — pool composition, reserves, LP supply, burn share, admin/control surface — all come from direct contract reads and are cleanly verifiable against three independent RPCs. The yield-flavored numbers — top-holder distribution, APR, fee volume — need a single indexer that no second source can cross-check on demand, so they can never carry a 3/3 verdict. The data reality reinforces the rule we set on day one: build the security card, not the yield card.

MetricSourceTriple-verifiable?Status in v1
Pool composition (token0/1, factory)RPC eth_call✓ yeslive on card
Reserves (getReserves)RPC eth_call✓ yeslive on card
LP supply & burn shareRPC eth_call✓ yeslive on card
Admin / control surface (owner)RPC eth_call✓ yeslive on card
Top-holder / LP concentrationIndexer (BlockScout)✗ single-sourceflagged, phase 2
Flash-loan-source historyeth_getLogs / trace~ partial · heavyphase 2
Fees · APR · volumeIndexer✗ single-sourceout of scope v1
USD / dollar valuePrice oracle✗ excluded by designnever — fork-mirror noise
!
The trap we refuse. The easiest way to make this tool “engaging” is to slap an APR number and a green/red light on every pool. But APR is single-source, and a red/green light is a buy signal wearing a costume — the moment it says “safe” and someone loses money, the tool is dead. Facts don't have that failure mode. So: numbers you can re-run, no scores you can blame us for.
Spike verdict The concept holds. The security-relevant metrics are fully triple-verifiable from RPC alone; the yield metrics that we deliberately de-emphasize are the ones that aren't. The data agrees with the design.
Roadmap

Where this goes next

This page is the feasibility proof: one real pool, every structural number triple-verified, in the platform's own design language. The path from here, in order: (1) lock the metric definitions and the exact fact-vs-advice display line; (2) decide the delivery model — pre-computed signed cards vs. a live-verifying backend, since tv.sh cannot run in a visitor's browser; (3) generalize the card to any PulseX pool, pDAI pools first; (4) add the phase-2 signals that need an indexer, clearly labelled as single-source and never mixed with the 3/3 facts.

Part of a bigger thing

The LP Risk Radar and the On-Chain Analyst's Path are two features of one community platform with a single thesis: learn to see the chain yourself, and never trust a number you didn't pull. More features follow. Same rule every time.