Glider Monitor: Continuous Threat Exposure Management for Web3

Glider Monitor: Continuous Threat Exposure Management for Web3

Continuous Threat Exposure Management (CTEM) for Web3: how the onboarding scan works, what's inside the vulnerability knowledge base, how the live 0-day/1-day exploit-to-detector pipeline turns a fresh mainnet hack into a check against your code, how multi-layer dependency-graph monitoring works, what a detector match looks like, pricing, and where Glider Monitor fits in a protocol's or capital management’s security stack.

Last updated: July 2026. Product details in this article (supported chains, pricing tiers, and customer list) are current as of that date.

What is Glider Monitor?

Glider Monitor is a continuous smart contract and capital security monitoring platform for live Web3 protocols and asset holders, built and operated by Hexens. It's a holistic production security tool that covers multiple ways your assets can be under danger, including checking your deployed contracts and capital against every vulnerability the industry produces, known and new, and tells you within minutes of a fresh mainnet exploit whether your own code carries the same bug. Onboarding takes a contract address and a chain; the free tier runs the full detector library.

That model has a name in Web2 enterprise security: Continuous Threat Exposure Management. Glider Monitor applies it to smart contracts and capital, so exposure is assessed continuously rather than at a single point in time: before, during, and after an attack.

If a pre-deployment audit is the seatbelt, Glider Monitor is closer to Cloudflare for Web3: an always-on protection layer sitting in front of your deployed protocol, updated as the threat landscape moves.

Glider Monitor runs on the same Glider engine and vulnerability knowledge base that the Hexens security team uses in audits and bug-bounty engagements.

In one sentence: an audit tells you what was true about your code on the day of the report; Glider Monitor keeps checking every day after that.

Pricing starts free, with paid tiers from $180/month. Supporting all of the major EVM chains, including Dependency-graph and custom-invariant coverage.

Glider Monitor capabilities at a glance

Glider Monitor provides eight core capabilities:

• Vulnerability knowledge base scanning: your code checked against a proprietary hand-authored detector set plus a community database built with the Ethereum Foundation Security team.
• 1-day/0-day exploit protection: a live stream of mainnet exploits, each converted into a detector query and run against your contracts within minutes of the original attack.
• Historical hack replay: documented exploits reconstructed and tested against your code.
• Dependency risk graph: your dependencies mapped and monitored, following the graph several layers deep on higher tiers, watching the invariants of protocols you rely on and the protocols they rely on.
• Custom invariants: a ready-made library of invariants for major protocols, plus your own defined in no-code form; verified on-chain every block, with support for off-chain data sources, and usable against positions you hold as well as contracts you deployed.
• Real-time direct-attack detection: attacking transactions, malicious contract deployments, and sudden state changes caught while the attack is still in progress.
• Precise, actionable findings: every detector match flags the vulnerable function and the exact code, explains the vector, and gives a concrete fix, or escalates to a human engineer when no standard fix applies.
• One-click setup: onboard with a contract address and a chain; no agents, no SDK, no code changes.

The rest of this article walks through how each of these works.

Why isn't an audit enough?

The smart contract security conversation has been dominated by pre-deployment audits for years, and that part of the market is mature. Post-deployment smart contract security, what happens after the audit report lands in your inbox, has been far less structured.

An audit reports what was true about a specific commit hash on a specific date. After that, three things start to drift.

The threat landscape keeps moving. Protocols get hacked continuously, and every hack exposes a new vulnerability. The knowledge is public. It just never reaches your code, because almost no one goes back and re-checks their own contracts against every fresh exploit.

Dependencies ship changes. The protocols you build on (oracles, lending markets, AMMs, cross-chain messaging layers) develop their own bugs, roll out upgrades, and change governance parameters. An upgrade lands in one block and your next call hits the new code. You inherit all of that risk without changing a line of your own code.

Your own code keeps evolving. New modules, new integrations, new chains, governance-triggered changes. The code that was audited is rarely the code actually running six months later.

None of this is covered by a static audit report. Most teams have filled the gap with transaction alerts, a bug bounty, and a measure of hope. Glider Monitor is the structured answer to that gap.

How does Glider Monitor work?

Glider Monitor runs on multiple modules. The engine, Glider, preprocesses every contract on a supported chain into queryable data; the knowledge base is a growing library of vulnerability detectors, each written as a query. Detection is simply running those queries against your code continuously, much like running a SQL query against a database.

Three sources feed the Glider Monitor knowledge base: detectors hand-authored by Hexens from real audit findings, a community set built with help of the Ethereum Foundation Grant Program, and a live stream of exploits happening on-chain right now, with each new hack converted into a query automatically, within minutes. On top of contract-level detection, Glider Monitor maps your dependency graph and verifies custom invariants you define.

The full picture: when you onboard a contract or an address, every existing detector runs against it once. From then on the workspace stays live, and every new detector, including one born from an exploit that happened an hour ago, is checked against your code automatically. When something matches, it surfaces as a finding and fires the response mechanisms you've configured.

The sections below break down each part: the opening scan, the three kinds of coverage (prevent, react, monitor), the knowledge base behind them, and what a detector match looks like when one fires.

What happens when you onboard a contract or an address

Before the continuous part begins, Glider Monitor runs a full opening sweep. You provide an address list and the chains; Glider Monitor does the rest in one pass:

• Sets up your workspace and notification channels.
• Runs your contract against the Hexens proprietary attack-vector knowledge base.
• Runs it against the community attack-vector knowledge base.
• Replays the full set of documented real-world hacks against it, checking whether any historical exploit path is reachable in your code.
• Builds your dependency graph, mapping oracle, vault, token, and other dependencies into a set of edges.
• Generates a snapshot risk report with an overall risk grade.

The output is a single verdict: hundreds of attack vectors and hundreds of historical incidents checked against your code, a dependency graph mapped, and a risk grade, all from one address. From that point the workspace stays live, and every new vulnerability entering the system is checked against you automatically.

Three ways live protocols get compromised, and how Glider Monitor covers each

Glider Monitor is organized around the three realistic ways a live protocol gets compromised. The same intelligence engine covers all three.

1. Prevent: 0-day and 1-day exploit protection

When a fresh exploit burns another protocol, the technique becomes public within hours. Copycat attackers immediately start scanning the chain for the same pattern. The window between disclosure and mass exploitation is short.

Glider Monitor closes that window. Glider Monitor runs a live stream of exploits happening on mainnet right now. Incident sourcing is partly outsourced: the live event feed that flags a fresh exploit is powered by DefiMon. Everything after that is in-house. When a new one lands on any chain, Glider Monitor reviews the incident, extracts the vulnerability that actually made it work, and converts that into a Glider query automatically. The query then runs against every monitored contract in the system. If your contract is vulnerable to the same vector, it surfaces as a finding before the copycats find you.

The mechanics are worth spelling out, because this is the core loop of the product:

exploit transaction confirms on mainnet          t = 0
        ↓  (trigger is the transaction itself, before any disclosure)
agent reconstructs the failed invariant from raw on-chain evidence:
call trace, storage and balance deltas, token flows, call context
        ↓
technique formalized into a Glider query
        ↓
query executes against YOUR monitored contracts         t ≈ 10 min
        ↓
verdict either way: a match names the function and explains
why it is exploitable; no match means you are told you are clear
        ↓
configured response mechanisms fire (webhook, Telegram, Slack)
        ↓
same query sweeps the rest of the chain (~2M recent contracts)   t ≈ 15 min

Put another way: every new DeFi hack becomes a detector for your contracts. The exploit that drained a protocol fifteen minutes ago is already a query that has finished checking whether the same path exists in your code.

Two things about that loop are worth naming. The trigger is the exploit transaction itself, the moment it confirms, not a disclosure, not a write-up, not a tweet. And you get an answer in both directions: a clean result is reported as a clean result, so "we checked and you are not exposed to this one" is an output of the system, not silence.

This runs at chain scale because of the Glider engine underneath. Glider preprocesses the contracts on a chain into queryable data, and a detector runs against it much like a SQL query runs against a database. That is how a single query can be evaluated across millions of contracts in minutes rather than days. It is the same engine Hexens auditors use to hunt for bugs offensively; Glider Monitor points it defensively, at your code.

This is the step most alert channels skip. Plenty of products, and plenty of Twitter accounts, will tell you a hack occurred. Far fewer then answer the question that actually matters to you: does my contract contain the same bug? Answering it requires formalizing the exploit into a precise query and running it against your code, which is exactly what the Glider engine was built for, and why the answer comes back as an analysis of your code rather than a keyword match.

The verdict is binary and continuous: safe or exposed, for every vulnerability the industry has surfaced, checked against your code.

What the pipeline found in its first two weeks

Hexens ran this loop for a couple of weeks and published the result: twelve live exploit incidents went in; 198 confirmed-vulnerable deployments came out. These were real contracts, live on Ethereum and BSC, each carrying a bug already observed being exploited elsewhere. Those 198 span 80 distinct codebases and nine bug classes, meaning each vulnerable pattern was live in two or three places at once on average.

"Confirmed" is load-bearing here. Each one means the system read the contract's own code and traced a reachable path from an entry point to the vulnerable behaviour, rather than noting that the code resembled something. What that path consists of depends on the bug class: for a value-extraction bug it is attacker-controlled input reaching a sink that moves value with no guard in between; for an access-control or initialization bug it is a privileged path reachable by someone who should not reach it. Candidates that share the shape of the bug but not the reachable path are dropped and never counted.

Bug class	Confirmed live deployments
Burn-from-pair + sync() reserve manipulation	116
Fee-on-transfer, recipient-debit	51
Unauthenticated swap/flash callback	14
Spot-price oracle (leverage settlement)	6
Spot-price oracle (reward/mint)	5
Phantom access control	3
Single-sided join/exit non-conservation	1
Unprotected initializer	1
Gas-rebate overpayment	1

Targets are not named and amounts at risk are not published. A still-vulnerable live contract with a dollar figure attached is a shopping list for attackers. Full methodology and per-class mechanics: The Exploit Is the Disclosure.

2. React: real-time attack detection

An attacking transaction is running against you, or an attacking contract has just been deployed. Every block that passes is value walking out the door.

Glider Monitor detects attacking activity in real time and provides what you need to respond while the attack is still in progress: a live attack feed, real-time capture of the attacking activity, and damage-control options.

3. Monitor: dependency risk and invariant monitoring

Dependency-driven risk is not a theoretical concern. Attacks on external dependencies and third-party infrastructure (oracles, cross-chain messaging layers, RPC and relayer infrastructure) accounted for over $630 million in DeFi losses in the first seven months of 2026 alone.¹ The largest DeFi incident of 2026 falls in this category rather than in the protocol's own application code: the rsETH bridge exploit in April 2026 drained $292 million through a forged cross-chain message enabled by a single-verifier configuration.^{1, 2}

Two details from the rsETH case make the point sharper. First, at the time of the exploit, 47% of applications running on the same messaging layer were using an equivalently minimal verifier setup, meaning hundreds of protocols shared the exposure without having written a single line of the vulnerable logic.³ Second, by the assessment of OpenZeppelin, the incident was not resolvable through a code review of any of the components involved, because the risk lived in configuration, integration, and trust assumptions rather than in a bug a differential audit would surface.² Immunefi's six-year loss analysis flags the same structural pattern: shared codebases, shared multisig signers, shared oracle providers, and shared infrastructure operators concentrate risk in a way that is hard to see from outside a protocol.³

When you build on Aave, Morpho, Curve, Balancer, or any other major protocol, you don't just inherit their code. You inherit their invariants. An oracle getting swapped out, a stablecoin depeg, a multisig threshold quietly dropping, a timelock reduction: any of these can expose your contracts even though your own code hasn't changed.

Glider Monitor automatically maps your dependency graph and watches the risk surface of every protocol and asset you transitively depend on, in real time, and can follow that graph up to four layers deep on the Lead tier, with significantly deeper traversal shipping in an upcoming release.

Here is what that depth means in practice. Say your contract sits directly on top of a vault protocol. Call that layer one. Glider Monitor monitors that protocol's critical invariants: debt bounds, share-price-never-drops, asset conservation, emergency-shutdown state. But that vault in turn rests on something else, say Morpho Blue. That is a deeper layer, a dependency you did not choose directly but inherited through the one you did. Glider Monitor can watch Morpho-level invariants too: reserve accounting conservation, governance changes, pending timelock reductions, borrow-never-exceeds-supply. A violation there flows straight through to your accounting. Graph depth scales with your plan; see pricing.

The graph also maintains itself. It refreshes every 15 to 20 minutes, so when you add a new integration or a dependency changes, it is picked up automatically: no API to call, no manifest to update, nothing to re-register on your side.

The framing that matters: Glider Monitor is not only asking "did my code break?" It is asking "did anything I depend on break?" down the dependency graph, continuously.

This is coverage no single audit provides. An audit looks at your code. It does not, and structurally cannot, keep watching the live state of a dozen protocols yours reads from, let alone the protocols those protocols read from.

Plus: your own invariants, checked every block

Some properties must always hold for your protocol: total supply matching balances, a collateral ratio staying above its floor, an owner address that never changes. When one of these silently breaks, it is often the first sign of a live exploit.

Glider Monitor ships a large library of ready-made invariants for major protocols, so the common cases are covered without writing anything, and lets you add your own on top. Custom invariants are created in the portal in no-code form, and Glider Monitor starts tracking them immediately: verified continuously, on-chain, every block, with an instant alert the moment one is violated.

Invariants are also not limited to contracts you deployed. You can write one against a position you hold: the health factor of your leveraged position on Aave, for example, checked every block, with an alert before liquidation rather than after it. That makes the invariant system useful to anyone holding on-chain exposure, not only to teams shipping smart contracts.

Two things extend this further than most teams expect. Invariants are not limited to on-chain state: they can query off-chain sources too, including internal databases and external data feeds, with the trade-off that off-chain checks carry a natural IO delay where on-chain-only checks run sub-second. And if your team already does formal verification, existing specs can be ported directly into live invariants, turning properties you proved at audit time into conditions monitored in production.

Invariants also cover the governance and ownership surface that plain transaction monitoring tends to miss: multisig threshold changes, owner changes, and similar configuration drift are supported use cases through the dependency graph and invariant system.

What's inside the Glider Monitor knowledge base

The intelligence behind Glider Monitor comes from three layers.

A proprietary attack-vector database, hand-authored by the Hexens security team and distilled from several hundred audits and bug-bounty engagements. Every detector is authored from a real finding, not generated by an LLM and not a generic pattern. The detectors span the categories where real money is lost: oracle and price manipulation, access control and privileged functions, reentrancy and callback abuse, Uniswap V4 hooks, cross-chain and bridge mints, proxy/upgrade/initialization bugs, token behavior anomalies, signature and proof verification, governance and timelocks, and low-level code-quality traps. The full set stays private; representative categories are shown in the product.

A community attack-vector database, most of it crowdsourced in a joint collaboration with the Ethereum Foundation Security team, with open contributions from researchers across the ecosystem. Queries carry a rarity tier (Legendary, Epic, and so on) as a quick read on how severe and how rare the pattern is. Covered issues include uninitialized UUPS/Beacon proxy implementations (the missing _disableInitializers class, rated Legendary), governance self-delegation, missing validator-duplication checks, and unverified external calls.

A historical hack replay set, where documented exploits are reconstructed and run against your contract to confirm the same path is not reachable. A representative sample:

Incident	Date	Vector	Impact	Reference
The DAO	Jun 2016	Recursive-call reentrancy drains the vault before balance is updated	~3.6M ETH (~$60M at the time)	post-mortem
Parity multisig	Nov 2017	Uninitialized library contract + delegatecall self-destruct	~$280M permanently frozen (not stolen)	Parity post-mortem
bZx / Fulcrum	Feb 2020	Flash-loan spot-price oracle manipulation, two attacks days apart	~$950K combined (~$350K + ~$633K)	PeckShield analysis
bZx iTokens	Sep 2020	Duplication bug in the iToken transfer path (a single misplaced line)	~$8M, covered from the insurance fund	incident analysis
Cream Finance	Oct 2021	pricePerShare oracle manipulation on the yUSD vault via direct token transfer	~$130M	SlowMist analysis
Wormhole Bridge	Feb 2022	Forged guardian signature verification bypass	~$326M (replenished by Jump Crypto)	Wormhole incident report
Euler Finance	Mar 2023	Missing health check on donation, enabling self-liquidation	~$197M (substantially returned by the attacker)	Euler post-mortem

...and hundreds more incidents beyond these. Each is replayed against your code, and you are told plainly whether it reproduced.

When a contract is onboarded, Glider Monitor runs all of this at once. From there it stays live: every new vulnerability entering the knowledge base is automatically checked against every contract already under monitoring.

What a Glider Monitor finding looks like

A finding (a confirmed detector match, referred to as a "hit" in the portal) can come from two directions: the live incidents pipeline (a fresh exploit somewhere on-chain, formalized into a query and run against your contracts) and the standing scan of your code against the full existing query database. Either way, when a query matches a contract you monitor, it surfaces in the portal and fires the response mechanisms you have configured, whether that is a webhook, a Telegram alert or whatever else you have wired in, tagged with the query ID that produced it.

A match gives you far more than "you may have a problem." A single query can match more than one of your contracts, and each match surfaces the specific vulnerable function and the exact code, along with the verdict and what to do about it. Here is the shape of it, schematically, using a reentrancy query that matched two contracts.

Contract 1: a withdraw() with a textbook reentrancy

function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount);
    (bool ok, ) = msg.sender.call{value: amount}("");  // external call
    require(ok);
    balances[msg.sender] -= amount;                    // state write AFTER the call
}

The match flags the exact line, the external call placed before the balance is decremented, and gives a concrete remediation: apply checks-effects-interactions (decrement before the call) or wrap the function with a nonReentrant modifier, then re-scan to confirm the path is closed.

Contract 2: a harvest() with cross-function reentrancy

function harvest() external {
    require(rewards[msg.sender] == 0, "reward pending");  // guard on state written AFTER the call
    uint256 reward = rewardSource.collect();             // external call hands control to another contract
    rewards[msg.sender] += reward;                       // credited using the call's own result
}

Same query, same class of bug, but here the verdict differs: a standard fix may well apply, but only a human can confirm it is safe once the contract has been reviewed in full. Instead of guessing, Glider Monitor routes you to a Hexens engineer.

That second case is the point worth dwelling on. This is automation plus human expertise, not "the AI will fix everything." When a standard fix applies, you get it instantly and in full detail. When it does not, Glider Monitor says so and puts a real security engineer in the loop, rather than confidently emitting a wrong patch, which for a live contract is worse than no patch at all.

How to set up Glider Monitor

Onboarding Glider Monitor requires exactly two things: a contract address and the chain it lives on. No agents to deploy, no code changes, no SDK integration.

1. Connect your contracts and addresses: add your deployed addresses in the Glider portal.
2. Choose your alert channels: Telegram, Slack, or a custom webhook into PagerDuty or internal systems. The webhook payload includes a severity field, so severity mapping is configured on your side rather than everything arriving as one flat priority level. The portal is the primary product; bots and workspace integrations are additional ways to consume the same data.
3. Glider Monitor starts monitoring: prevent, react, and monitor coverage from one place.

Supported chains (July 2026): All major EVM chains.

Glider Monitor vs other smart contract security tooling

Glider Monitor vs audits

Glider Monitor is not a replacement for an audit. It is the layer on top. Glider Monitor explicitly assumes you have been audited. It covers what an audit structurally cannot: new attack patterns discovered after the report, post-audit code changes, and dependency-driven risk.

Glider Monitor vs monitoring and detection platforms

Here Glider Monitor is positioned as a replacement, not an add-on. The competitive set among DeFi security monitoring tools includes Forta, Hypernative, Cyvers, and BlockSec Phalcon.

The dominant model in the category is transaction- and behavior-level: watch on-chain activity, alert when something looks anomalous or when a hack occurs somewhere. That layer is real and Glider Monitor includes it. The distinction is what sits on top of it:

• Exploit-to-detector conversion. Knowing a hack occurred is a different product from knowing whether your contract contains the same bug. Answering the second question requires formalizing the exploit into a precise query over contract structure and running it against your code. Glider Monitor does this on the Glider engine, the same query language Hexens auditors use to formalize vulnerabilities, which is why the answer is an analysis of your code rather than an approximate pattern match.
• Multi-layer dependency graph. Snapshot or single-layer dependency views are common. Glider Monitor follows the graph up to four layers deep and monitors the invariants of protocols you never integrated directly.

The honest framing: if your current setup is a transaction watcher plus hope, Glider Monitor covers strictly more surface. If you already run a mature detection stack, the incremental value is concentrated in the two layers above (plus the surface that is already covered by existing vendors - that is why Glider is not just an add-on but a more advanced replacement).

What to ask any monitoring vendor

Rather than assert what competing products do or do not do, here are the questions worth putting to any vendor in this category, including us, with our own answers stated plainly. Where the answer is limited by tier or by current coverage, that is stated rather than omitted.

Question to ask	Glider Monitor's answer
When a new exploit hits some other protocol, do you check my code for the same bug, or only tell me the hack happened?	Yes. The exploit is formalized into a detector query and executed against your contracts, typically 10 to 15 minutes after the exploit transaction confirms.
By what mechanism? Keyword or signature matching, or analysis of the code itself?	A query over preprocessed contract code, on the Glider engine, the same query language community already uses to formalize vulnerabilities.
Do I get told when I'm clear, or only when something matches?	Both. A clean result is reported as a clean result, along with what was checked.
Does a finding tell me where the bug is and how to fix it, or just that a bug exists?	The specific vulnerable function and the exact code, the vector, and a concrete remediation.
What happens when no standard fix applies to my contract?	You are told that, rather than given a guessed patch, and routed to a security engineer. Direct engineer access is a Scale and Lead feature.
Do you monitor the protocols I depend on, and how many layers deep?	Yes. Snapshot on Community and Growth; real-time from Scale ($900/mo). Graph depth 1 on Community, Growth and Scale; depth 4 on Lead.
Can I define my own invariants, and does it require writing code?	Yes, in no-code form in the portal, verified on-chain every block. 1 / 2 / 5 / unlimited by tier. Off-chain data sources and ported formal-verification specs are supported.
Where do your detectors come from?	The knowledge-base detectors are hand-authored by the Hexens security team from real audit and bug-bounty findings, plus a community set crowdsourced with the Ethereum Foundation Security team. In the 0-day loop, an agent writes the query from the exploit itself, because speed is the whole point there.
How many chains, and is every module available on all of them?	All of the major EVM chains.
Is pricing published, and is there a free tier?	Yes and yes. Free forever on Community, paid from $180/mo, no sales call required.

Glider Monitor vs Token Risks API

The Hexens Token Risks API answers a different question: token-level risk patterns such as owner control, approval logic, blacklist functions and ERC-20 compliance, the checks you want when deciding whether to integrate a token. Glider Monitor is continuous protocol-level monitoring of contracts you have already deployed. Adjacent layers, different problems.

A reasonable security stack for a live protocol: audit before mainnet, Token Risks API for token integration decisions, Glider Monitor as the production security layer between audits.

Glider Monitor pricing

Continuous threat exposure monitoring has existed in Web3 before, but as an enterprise product and very shallow surface (no 0day/1day protection, no dep graph or auto invariants, etc): undisclosed pricing, sales calls, contracts sized for protocols with nine-figure TVL. Glider Monitor starts at $180/month for automatic 0-day/1-day exploit monitoring and zero-delay attack detection, with a free tier below that. This is not a stripped-down version: every tier, including the free one, runs the full Glider vulnerability database.

Paid tiers add automation, lower alert delay, and direct engineer access. Community is free, forever. Upgrade any time, changes apply immediately, no contracts, no lock-in.

	Community	Growth	Scale	Lead
Price	Free, forever	$180/mo	$900/mo	Contact us
Max TVL	<$10M	<$25M	<$50M	Unlimited
Max contracts	<10	<20	<50	Unlimited
Vulnerability database scanning	✓	✓	✓	✓
0-day/1-day exploit monitoring	Manual	Automatic	Automatic	Automatic
Direct attack monitoring	Delayed	No delay	No delay	No delay
Dependency risks	Snapshot	Snapshot	Real-time	Real-time
Dependency graph depth	1	1	1	4
Custom invariants	1	2	5	Unlimited
Custom webhook	✕	✕	✓	✓
Access to Glider engineers	✕	✕	✓	✓
Glider IDE (custom queries)	✕	✕	✕	✓

Pricing current as of July 2026.

Who uses Glider Monitor

As of July 2026, Glider Monitor is monitoring contracts for protocol teams and capital allocators alike, including Polygon, PancakeSwap, Azuro, Mezen Capital, Thema Finance, Thesauros, Vault Street and KalqiX, Auto Finance, etc.

There are two distinct audiences, using the same product for different reasons.

Protocol teams. Any project holding TVL: live protocols that have been audited at least once and want structured coverage between audits. Here the question is "is my own code exposed?"

Funds, asset managers, and treasuries. If your capital is deployed into protocols you did not build, your exposure is their code, and you inherit every risk in it without any ability to fix it. Glider Monitor lets you monitor the protocols you are invested in exactly the way their own teams do: the same detector library, the same dependency graph, the same alerts. When a fresh exploit hits the market, you learn whether a position in your portfolio carries the same bug within minutes, rather than reading about it after the fact.

Worth noting for this use case: onboarding needs only addresses and a chains, and the engine reads contracts, positions, dependencies as they are deployed on-chain. That means a fund can monitor a portfolio protocol without any involvement from that protocol's team, and can watch several positions from one workspace. Dependency-graph coverage matters here too, since a portfolio protocol's exposure often comes from what it builds on rather than from its own code. Invariants extend this to the positions themselves: the health factor of a leveraged position, for instance, checked every block.

The same logic extends to enterprises where a stalled or compromised system is not an option.

The free Community tier makes Glider Monitor accessible to smaller projects; Growth and Scale fit production protocols; Lead is for larger teams and allocators that want custom integrations, the Glider IDE for writing their own vulnerability queries, and a direct channel to Hexens engineers.

Glider Monitor is probably not the right fit for pre-mainnet projects still iterating daily. At that stage an audit is the priority, not continuous monitoring of code that changes every day.

What security researchers say about Glider Monitor

Glider Monitor drew attention from security researchers and audit teams outside Hexens as soon as it launched.

Preetam Rao, CEO and co-founder of QuillAudits, spent several days digging into how it works and wrote up his take. His framing maps the core idea onto how detection already works in Web2, where a newly observed attack becomes a new detection rule that defenders immediately scan their own systems against. He singled out four things: turning every exploit into a new detection opportunity, continuous monitoring in place of one-time audits, dependency-risk monitoring, and invariant monitoring, reading Glider Monitor as a sign of where Web3 security is heading, from point-in-time audits toward continuous coverage.

Read Preetam's full thread →

---

Glider Monitor is available now. Enroll for free or book a demo.

Sources

1. Crypto Economy, July 2026. Cumulative 2026 DeFi losses from attacks on third-party infrastructure and external dependencies. https://crypto-economy.com/defi-loses-630m-to-attacks-targeting-critical-third-party-infrastructure/

2. OpenZeppelin, April 2026. Analysis of the rsETH bridge exploit and why point-in-time code review did not cover it. https://www.openzeppelin.com/news/lessons-from-kelpdao-hack

3. Immunefi, 2026. The Ecosystem Vulnerability Scoreboard: 6 Years of DeFi Loss Data. Share of applications on the same messaging layer using an equivalent minimal verifier configuration at the time of the exploit, and six-year shared-dependency concentration analysis. https://immunefi.com/blog/research/the-ecosystem-vulnerability-scoreboard-6-years-of-defi-loss-data/