Ninja Position

Demo

About

Portfolio dashboards like DeBank are great at showing what you hold: balances, positions, and yields across protocols, all in one screen. What they cannot show is what your holdings stand on. In the KelpDAO/rsETH incident, rsETH was abnormally minted, the attacker deposited it into Aave as collateral and borrowed out WETH at scale, and the shared WETH pool ran dry — so depositors holding zero rsETH could no longer withdraw their WETH-side assets. On a holdings-based dashboard, those users looked perfectly fine until the moment they couldn't withdraw. The information that mattered — "an incident at a protocol you never touched is about to reach you through a shared pool" — exists on no screen today. That is the layer we built: a dashboard of dependencies, not holdings. It shows what your assets stand on, alerts you when trouble somewhere else can reach you, and points to exits that don't stand on the same ground. Four capabilities: 1. Automatic dependency graph construction — Enter a wallet address, and the dashboard traces collateral settings, shared pools, and backing chains on-chain from your positions (e.g., WETH-side and USDC-side on Aave), rendering both Active edges (dependencies you actually use) and Latent edges (dependencies you are structurally exposed to) in one graph. It automatically discovers the 20+ contracts you never registered but actually depend on. 2. Real incident replay — The dashboard captures incidents like KelpDAO, and this build replays them from actual on-chain history, showing how contamination propagates through the graph toward YOU. 3. Alerts — When an incident somewhere else can reach your assets, an alert arrives. 4. Exit recommendation — The dashboard presents exit candidates ranked by shared-edge count with the incident subgraph, so the "action to take" is on screen with its evidence: which candidates share edges with the fire, and which share none. Understanding, alert, and next action live in one view — fund movement itself stays in the user's hands. This hackathon build reads the chain directly (RPC + Multicall3); we did not wire Curvegrid MultiBaas in this time. But the architecture is deliberately shaped so MultiBaas slots straight in for live monitoring of the next incident: the dependency graph outputs exactly what MultiBaas takes as input — a list of contracts worth watching. Register that list through MultiBaas contract registration (with automatic ABI fetching and proxy resolution), let the Indexer and event.emitted webhooks watch the perimeter continuously, and aggregate the views with Event Queries. The graph discovers what to watch; MultiBaas can do the watching — a dashboard that doesn't just show your holdings, but shows what your holdings stand on, and what to do when it burns.

How it's made

Core engine: The dependency-graph engine is built in TypeScript. Given a wallet address, it runs a BFS reachability trace across protocol adapters (Aave v3, Spark, Fluid Lite, LST/LRT backing chains such as rsETH to stETH to ETH), reading on-chain state directly via Multicall3 so hundreds of eth_calls collapse into a handful of RPC round-trips. Edges are typed into three classes — Active (positions you actually hold), Latent (collateral-eligibility and shared-reserve links you are structurally exposed to), and Asset-backing (what your token is redeemable into). This vocabulary is the heart of the project: it is what lets us show that a wallet holding zero rsETH can still be hurt by an rsETH incident. Incident replay: The engine captures incidents like KelpDAO, and this build replays them from real on-chain history using block-pinned reads: we re-run the graph at T=-1/T0/T1/T2 and diff the states, so the propagation animation is derived from actual chain data, not a mock. When the incident reaches you, an alert fires. Exit recommendation (built at the hackathon): For each exit candidate we compute the number of shared edges with the incident subgraph and rank candidates by edge-disjointness — the recommendation is a graph computation, not a hardcoded rule. The dashboard shows the ranking with its evidence (shared-edge counts per candidate), so an operator can see not just "go to USDC" but why USDC and not another LST venue. Where MultiBaas fits (designed, not yet wired): To be transparent: this build does not run on MultiBaas. Replaying a past incident requires block-pinned bulk state reads — hundreds of low-level calls per graph — which is direct RPC/Multicall3 territory, so the current build talks to the chain directly. But the other half of the design, live monitoring of the next incident, is exactly MultiBaas-shaped, and we shaped the seam deliberately: the BFS outputs the wallet's true monitoring perimeter — the 20+ contracts the user never registered — as a machine-readable list, which maps one-to-one onto MultiBaas contract registration (with automatic ABI fetching and proxy resolution). From there, event syncing and event.emitted webhooks would watch the perimeter continuously without us building our own indexer, and Event Queries would drive the dashboard aggregations — live, rather than replayed. The division of labor we designed for: bulk block-pinned reads = direct RPC; continuous events, history, and aggregation = MultiBaas. This split is also our product feedback in the README. The hack we're proud of: the graph decides what to watch — and can hand that list straight to middleware like MultiBaas to do the watching. Monitoring perimeters in every existing tool are user-enumerated lists; here the dependency graph auto-generates the list. That inversion — discovery upstream of monitoring — is what turns a portfolio viewer into an operational dashboard.