[DRAFT: NON-CONSTITUTIONAL] Integration of Hexens’ Glider Platform into the Arbitrum Ecosystem

[HaykK]

Abstract

This proposal requests 1.5M ARB to integrate Glider, Hexens’ smart contract intelligence and security engine, into the Arbitrum ecosystem. Glider will deliver chain-wide contract labeling, explorer integration, automated risk warnings, a public API and screener, 1-day protection for protocols, and IDE access for the Security Council. The goal is to strengthen Arbitrum’s security and transparency, prevent costly exploits, and improve developer and user experience across the network.

Motivation

Arbitrum protocols and users have suffered significant losses from smart contract exploits and scams – approximately $38M in 2023 and $114M in 2024, the third-highest among all chains.

Source

Analysis shows that vulnerabilities leading to over 90% of these historical exploits (>$88 million worth) could have been detected by now using Glider, if advanced on-chain code analysis tools were in place. Arbitrum is one of the most active Ethereum Layer-2 networks, recently processing up to 2.8 million transactions in a day and reaching milestones like 200 million total transactions. With this explosive growth in usage and a CAGR of ~45% of new contracts deployed, the tooling for understanding on-chain activity has not fully kept pace. The community and developers lack easy ways to analyze what these contracts do beyond reading raw code on Arbiscan.

Rationale

The Arbitrum DAO’s mission, is to foster the growth of a secure, transparent, and user-friendly ecosystem. This proposal directly advances those goals by making smart contracts on Arbitrum more understandable, more secure, and more accessible to both builders and users. This proposal introduces Glider, a next-generation smart contract analysis platform by Hexens (Hexens is an approved audit provider under the Arbitrum Audit Program), into the Arbitrum ecosystem as a high-ROI public good. Arbitrum can deploy a proactive security infrastructure that potentially averts tens of millions in future hacks – effectively paying for itself many times over. The integration poses no changes to the Arbitrum protocol (it’s entirely off-chain and additive), so it carries no risk to network performance or consensus.

• Security: Continuous vulnerability detection, 1-day protection, and alerts for risky contract patterns strengthen the network’s resilience against exploits and safeguard user funds.

• Transparency: Comprehensive labeling and explorer integration turn opaque bytecode into clear categories, giving the community, delegates, and everyday users actionable insights into what contracts do.

• Public Good: Glider’s outputs, such as risk warnings and public dashboards, benefit the entire ecosystem without privileging any single party — mirroring Arbitrum’s ethos of open access and shared infrastructure.

• Empowerment: Developers, researchers, and the Security Council gain powerful tools (Glider IDE, API access, custom queries) to improve governance decisions and accelerate innovation.

  Specifications

  What Glider Will Deliver:

• Chain-Wide Code Query Engine: Glider indexes all verified smart contracts on Arbitrum and enables complex code queries across the entire chain in seconds. This unprecedented capability lets security experts (including Arbitrum’s Security Council) to swiftly find specific logic patterns, clones of known protocols, and common vulnerability signatures anywhere on the network; a level of insight never before possible on any chain.

• Comprehensive Contract Labels & Explorer Integration: Glider will generate a database of over 150 meaningful labels covering contract types and traits (e.g. various ERC standards, upgradability, proxy patterns, DeFi protocol forks, etc.). Every verified contract on Arbitrum will be tagged with relevant labels, enabling builders and analysts to identify trends (for example, spotting surges in “Liquid Staking” or new “ERC-4626” contracts) and making the chain far easier to navigate. These labels will be integrated into Arbiscan – anyone browsing Arbiscan will see rich tag annotations on contract pages, enhancing transparency and comprehension across the ecosystem.

• Automated Risk Warnings for Users: Glider will perform quick token risk analysis on all existing and newly deployed contracts to spot red flags such as hidden fees, honeypot behavior, hidden mint/burn functions, pausability, upgradability permissions, and more. Risk indicator labels (e.g. “ Honeypot”, “ Hidden Fee”, “ Proxy: Admin Can Upgrade”) will be displayed on the explorer or other integrated software (e.g. wallets), with explanations so that users are warned in advance when a contract they’re viewing has potentially dangerous functionality. This publicly accessible “risk dictionary” empowers the community to avoid interacting with scams or risky contracts, building user trust and safety into the UX of Arbitrum.

• Public API Access & Glider Screener UI: To maximize community benefit, Glider’s data will be offered as a public good. Developers and protocol teams will be able to request free API keys (with appropriate rate limits) to programmatically query contract labels and risky findings, enabling them to integrate on-chain security checks into wallets, dApps, portfolio trackers, or any other applications. For everyday users, a web-based Glider Screener interface will allow fast token/contract analysis – anyone can input a token or contract address and immediately see its labels, risk flags, and other diagnostic information. This lowers the barrier for users to perform due diligence and make informed decisions, democratizing access to security insights that were previously available only to experts.

• “1-day protection” Self-Service for Protocols: Beginning around Month 4, Glider will activate a 1-day protection program for verified protocol teams. Teams will be able to submit their smart contracts through a secure portal to be included in Glider’s continuous vulnerability monitoring. In the event a novel exploit or 0-day vulnerability is identified in the wild, Hexens will promptly develop a detection query set and scan all indexed contracts, including those submitted, within 24 hours. If a vulnerability match is found, the affected team will be alerted immediately through secure channels, enabling them to patch, pause, or mitigate the issue before it can be exploited. Basic KYB and proof-of-ownership will be required to ensure only authorized teams access this protection. This mechanism minimizes attacker lead time and can prevent multi-million dollar losses across the ecosystem.

• Glider IDE Access & Ongoing Security Operations Support: Authorized members of the Arbitrum Security Council will receive access to the full Glider IDE for Arbitrum, a powerful interactive environment to write custom queries and conduct deep chain-wide analysis in real time. This allows Arbitrum’s security and data experts to proactively hunt for vulnerabilities or verify the impact of network upgrades (e.g. find all contracts that would be affected by a change) on their own. Hexens will also provide at least 100 hours of expert query engineering support to assist Arbitrum in crafting specialized queries and analytics over the next year. In parallel, Glider will serve as a continuous Security Operations Center (SOC) for Arbitrum; it will run automated scans for dozens of known vulnerability types (reentrancy, faulty signature verifications, dangerous external calls, etc.) on an ongoing basis, and maintain an internal dashboard tracking live security metrics (number of flagged contracts, exploit trends, etc.). The Hexens team will deliver monthly security reports to the Security Council summarizing key findings and chain security posture (with the first reports starting a few months into operation once enough data is collected). If any critical issue is identified (e.g. a newly deployed contract shows a bug identical to one that caused a past hack), Hexens will perform responsible disclosure – privately notifying the affected project and the Arbitrum security team so fixes can be made before public disclosure. Overall, Glider IDE and the SOC monitoring ensure Arbitrum has unparalleled visibility into on-chain risks and the tools to act decisively, reinforcing the ecosystem’s security long-term.

Total Funding Requested: 1,500,000 ARB, disbursed in milestone-based tranches tied to the successful completion of deliverables (detailed in the roadmap below) for a 12-month period. This proposal is submitted as a Non-Constitutional AIP under the Arbitrum DAO Grants Program (security & developer tooling category). It will follow the standard governance process (forum discussion, Snapshot, on-chain Tally vote). Any unused funds will be returned to the DAO treasury if applicable.

Implementation Roadmap and Timeline (Phased Plan)

Phase 1 – Setup & Technical Integration (Month 0 – 1)

• Infrastructure: Deploy Glider indexer on Arbitrum, connect to archive/current nodes, build databases, and ingest all verified contract code—built to handle millions of contracts.

• Validation: Run sample queries (e.g., selfdestruct, proxy patterns) to confirm accurate indexing and chain-wide search performance.

• Deliverable: Backend live and query-ready, server setup done; Hexens submits an integration report within ~1 month of approval.

• Funding: 200k ARB on milestone acceptance.

Phase 2: Contract Labeling, Explorer Integration, API Access & Risk Assessment (Target: ~1 Month Post-Setup)

Once the Glider engine is up, Phase 2 brings its capabilities to the Arbitrum community by rolling out the labeling system, user-facing integrations, and initial security features.

• Full-Code Label Dataset (150+ tags): Glider queries tag every verified contract with categories such as ERC-20/721/1155, proxy type (ERC-1967, clones), DeFi primitives (AMM, lending), upgradability status, and fork fingerprints (e.g., “Uniswap V2”). Manual QA refines accuracy, giving Arbitrum community a panoramic view of code trends (e.g., Liquid-Staking growth). Below are examples of labels:

• Arbiscan Explorer Integration (Public Launch): Hexens will collaborate with the Arbiscan team to integrate the label data into the public explorer. Once live, users now will see annotations like “ERC-20 • Pausable” or “Proxy • Upgradable (Admin 0xABC…)”. Risk-related tags display a icon with concise explanations. Each label or flag will include a brief description. As an example Label A, (BEP20, Liquidity Pool), Label B, Label C ( PalmSwap: LP Contract)

• Risk Indicators: Glider’s Token Risks API scans every contract for hidden fees/taxes, blacklist logic, suspicious mint/burn: 15+ similar risks. Each address receives a risk score; Arbiscan then shows labels such as “Honeypot—selling disabled” or “Hidden Fee.” This core check-set, covering the most common Arbitrum scams and risks, will be live by Month 1 after Setup. The DAO/Security Council will decide which flags appear publicly. Instant, user-facing warnings give traders live safety cues and outclass existing token-security tools by covering dozens of on-chain risk vectors. During a recent check of 60 random tokens, Glider checked 1020 risks and had 99.3% true positive rate. It found risks in 2 times more tokens and found 2.5 times more risks than the existing solutions.
  Free version for playground is available here https://hexens.io/solutions/token-risks-api/playground
  Blog article: https://hexens.io/blog/Glider-Token-Risk-Scanning-for-Traders

• Public API Access: To further extend Glider’s benefits as a public good, Phase 2 will include the release of a Glider API that developers, teams, or advanced users can use to query the label and risk data free of charge. Interested parties will be able to obtain API keys (free of charge) with rate limits (RPS/RPM) to prevent abuse. This empowers wallet developers, block explorers, portfolio trackers, and other dApp builders to incorporate Arbitrum contract safety checks directly into their products. For instance, a wallet could warn a user if they are about to interact with a flagged high-risk contract by leveraging the Glider API in the background.

• Glider Screener UI for Users: Hexens will also release a web-based “Glider Screener.” Any user—no dev skills required—can paste a contract address and instantly see its Glider profile: labels, risk flags, and an easy-to-read score. In one click, the screener delivers an “intel report” on any Arbitrum contract, aiding due-diligence for token buyers and researchers. It complements Arbiscan, offers quick stats (e.g., “95 % code match to XYZ” or “No critical risks”), and, as a free public good, lets the whole community tap Glider’s on-chain security insights.

• Deliverables (Phase 2): The public launch of Glider’s labeling and risk analysis features on Arbitrum:

(a) A community-accessible dashboard or explorer integration with the initial contract labels database (150+ labels applied to all verified contracts), and a Dashboard with statistics and trends

(b) Risk warning labels live on Arbiscan (as approved by the DAO/Security Council),

(c) Open API endpoints for third-parties to fetch label/risk data (with documentation),

(d) the Glider Screener web UI available for users’ quick token safety checks. By the end of this phase, in 1-2 months after setup, any Arbitrum user or builder will have free access to rich security metadata for contracts – through Arbiscan, via API, or via the Screener interface – marking a major step forward in chain transparency and user protection.

• Funding: 350,000 ARB upon completion of Phase 2 deliverables.

Phase 3: “1-day protection” Protocol Self-Service (Target: ~Month 4)

Phase 3 expands Glider’s protective umbrella to actively involve protocol teams, offering them ongoing monitoring against novel 0-day attacks.

• One-Day Exploit Protection: Glider’s “1-Day Protection” turns the scanner into a live immune system. When a new 0-day emerges—on Arbitrum or any EVM like chain—Hexens crafts a detection query within hours. Glider then scans every indexed contract and, within 24h, alerts registered projects in 1-day protection if they’re vulnerable. Teams fix issues before attackers strike, giving Arbitrum a constant edge against fresh exploits.

• Outreach & Adoption: Hexens will broadcast “1-day protection” via announcements, docs, and short workshops, targeting small or high-risk projects. The more teams onboard, the wider the 1-day alert coverage—and the safer the chain for users

• Phase 3 Deliverables: Portal live with access to 1-day protection for exploit-alert engine. Any Arbitrum team can register, scan contracts, and receive warnings; shifting the ecosystem from reactive to proactive security.

• Funding: 400,000 ARB upon completion of Phase 3.

Phase 4: Glider IDE Access, Security Monitoring & Ongoing Support (Continuous from ~Month 1 onward)

The final phase encompasses the long-term integration and operation of Glider as a security cornerstone for Arbitrum. Many of these efforts begin early (some in parallel with earlier phases) and continue throughout the year, providing ongoing value.

• Glider IDE for Security Council: From Day 1 of integration, the Security Council gets a secure web IDE to run custom chain-wide queries – for example, “list all contracts that call a particular deprecated function,” or “find every contract that would break if we change X in the protocol,” or “identify any contract created by address Y that has admin privileges.” They can perform variant analysis of known vulnerabilities (to see if other contracts have similar weaknesses), conduct investigations during an incident, or simply gather metrics on the state of the ecosystem’s code. Built-in user permissions keep sensitive searches private.

• 100 Hours of Expert Query Support: Hexens engineers will provide up to 100 hrs of query help over 12 months in writing complex queries, interpreting results, or creating new labeled insights tailored to Arbitrum’s needs (log of used hours tracked, 300 ARB/hr). Unused hours roll forward or remain unspent and funds not requested.

• Security Operations Center for Security Council: Once Glider is integrated, it will continuously run its arsenal of security queries (25 known vulnerability types currently in query sets and growing) across the chain as new blocks and contracts come in. This includes various forms of reentrancy, insecure external calls, flawed signature verifications, logic errors, etc. – essentially an automated audit running nonstop in the background. The results feed into an internal Security Operations Center dashboard maintained by Hexens. This SOC dashboard aggregates real-time data on Arbitrum’s security posture. Hexens will deliver monthly security reports to the Security Council that summarize key insights and SOC dashboard will be enabled starting around Month 6–7. Such information helps Arbitrum governance understand where the ecosystem’s weak points are and could guide decisions (e.g., funding security audits for a particularly bug-prone category of projects).

• Early Warning & Incident Response: On critical findings, Hexens discreetly alerts affected projects and the Security Council, following strict responsible-disclosure rules.

• Ongoing Maintenance and Updates: New labels, queries, and cross-chain exploit detectors are added as threats evolve from all EVM chains, with community feedback shaping priorities.

• Deliverables (Phase 4):

1. IDE live with Council access.

2. 100 hrs support delivered on demand.

3. Automated scans + dashboard running 24/7.

4. Monthly security reports.

5. Documented early-warning interventions (if triggered).

• Funding: 550,000 ARB

Conclusion

Glider can block 90%+ of exploit patterns seen on Arbitrum—about $87 M in avoided losses. Fewer hacks mean safer users, confident builders, and a Security Council with real-time intel.

The ask is 1.5 M ARB, a 0.6% fraction of the $97.7 M already lost. Funds are milestone-based and any surplus returns to the treasury. Because Glider runs off-chain, it needs no protocol changes—pure upside.

Approving this proposal funds a public good that makes Arbitrum one of the most security-forward chains making Arbitrum THE most security forward chain. It supports the DAO’s goals of stronger tooling, security, and user experience.

Hexens’ Glider offers high ROI: fewer attacks, higher trust, and unrivaled code insight. We urge delegates to vote yes and give Arbitrum the protection it deserves.

[karpatkey]

This seems interesting, but we’re curious to know if this topic has been discussed with the Arbitrum Foundation or Offchain Labs already?

As these two AAEs are the core technical contributors to the Arbitrum ecosystem, it would be useful to get their feedback.

[HaykK]

Thanks for the thoughtful question. We fully agree that getting technical feedback is essential.

We discussed Glider capabilities beforehand, both with Arbitrum Foundation and Offchain Labs, and now we’ve reached out to both to share the proposal and invite any comments or suggestions from their side.

Our team would be more than happy to align with any integration processes, API standards, or labeling conventions they suggest. Additionally, our implementation remains fully off-chain and non-invasive to protocol operations.

[stonecoldpat]

Hi @HaykK

As a DAO, we are trying to move towards having a more efficient service provider counterparty model facilitated by AAEs (i.e., service providers are no longer lobbying the DAO with their own proposals), especially for significantly large asks like 1.5 million ARB. If you are already in touch with folks at the AF or OCL, then it would be great to keep that process going.

[PGov]

This proposal is a pretty ambitious attempt to make on-chain security and transparency more accessible. The issue of over $150M lost to exploits in the past two years, and most of those incidents could have been mitigated if the right tools had been available is blunt and fair. The deliverables outlined are wide-ranging. By promising more advanced infrastructure for experts and governance participants—such as chain-wide query capabilities, Glider IDE access, and “1-day protection” for protocols that want to be alerted of emerging exploits in real time.

Overall, we think the biggest point for community discussion will be around funding and accountability for 1.5M ARB, which is pretty substantial. Given Hexens’ track record as an approved audit provider, there’s some credibility, but it’s still important to evaluate whether the DAO wants to commit this amount compared to other security investments.

We’re curious as a whole as to if Arbitrum should prioritize ecosystem-wide tools like Glider that act as preventive infrastructure, or should resources be spread more across targeted audits and bounties? In some sense, this proposal shifts the mindset from “patchwork defense” to building a baseline layer of transparency and monitoring. If the DAO wants to set a precedent for funding large-scale public goods, this could be an interesting case study. But it definitely requires the community to weigh costs against measurable impact over the first 6–12 months.

[HaykK]

Thanks for the thoughtful feedback. We agree that reputation alone isn’t enough for funding at this scale, which is why the 1.5M ARB request is milestone-based and disbursed only after deliverables are met. Three of the five components will be live within the first 1–2 months, with 1-Day Protection and the SOC following around Month 4. This ensures accountability and gives the DAO flexibility if expectations aren’t met.

Our goal is to provide Arbitrum with a baseline layer of prevention and transparency that complements, not replaces, audits and bounties. As a cybersecurity company, Hexens has always promoted a defense-in-depth approach: multiple audits, bug bounties, and continuous monitoring together create the strongest protection.

[Doo_StableLab]

Based on information we have so far, we would be voting against it if it comes to voting phase. It’s a large budget request and considering how users interact, potential collaboration with wallets themselves such as Metamask or Rabby would be more helpful before the users interact with such.

[HaykK]

Thanks for the comment. Yes, wallets are indeed a critical interface where risk warnings add value, and Glider already provides APIs and risk scores that can be integrated by them. That said, this proposal is infrastructure-first: by funding the chain-wide analytics backbone, Arbitrum ensures that wallets, explorers, and other apps can plug into reliable data.

Wallets like MetaMask or Rabby may choose to integrate or purchase these services later, but the DAO’s investment would immediately reduce scams and rug pulls on Arbitrum itself, strengthening its reputation as the safest chain to build and trade on. Our testing shows that traders spend ~15% more when risk scoring is available, which translates into more revenue for healthy projects and additional transaction fees for Arbitrum.

It’s also worth noting that risk scanning is only a fraction of the proposal, about 150,000 ARB of the total budget. It sits within Phase 2 (Contract Labeling, Explorer Integration, API Access & Risk Assessment), which totals 350,000 ARB. The broader deliverables include chain-wide labeling, comprehensive security assessments, 1-Day Protection, and SOC/IDE access — none of which can happen without first integrating Glider into Arbitrum. So while wallets are an important downstream user, this proposal is about laying the core foundation for ecosystem-wide security and transparency.

[jameskbh]

Hello!
Thanks for your proposal!

@HaykK

We discussed Glider capabilities beforehand, both with Arbitrum Foundation and Offchain Labs, and now we’ve reached out to both to share the proposal and invite any comments or suggestions from their side.

Curious to understand if they suggested you to come to the DAO to ask for funding (as it seems it was not the case). Can you add more colours on what was their feedback, if any?

[HaykK]

Hello.

The conversations we had with both the Arbitrum Foundation and Offchain Labs at the end of July–August were mainly focused on demonstrating Glider’s current capabilities and features under development. The impression we received was positive, though we did not discuss commercial terms at that time, nor were we directed by them to seek DAO funding.

Submitting to the DAO was our own initiative, as we believed that given Glider’s broad feature set and relevance across multiple stakeholder groups the treasury route would be the most appropriate. We also felt it didn’t fit neatly into existing grant programs. That said, based on the comments here, it seems there may be other tracks available, and we’re very open to exploring those options if that better serves the ecosystem.

[cupojoseph]

Arbiscan labels work fine, not sure what the value of this is exactly?

The only really interesting part of this to me as a builder is security scans. The rest kind of seems like fluff. But I would prefer this to be a service offered through the DAO’s security subsidy fund that anyone building something cool can request a subsidy to access the security tools. If builders dont request the product then they probably wont use it / integrate it, and Arbitrum DAO should not pay for things people might use upfront.

[HaykK]

Super valuable feedback, but let’s be clear. Security scans don’t happen in a vacuum. Without chain-level integration, there are no real-time alerts, no meaningful labeling, no SOC dashboard, no 1-Day Protection. Integration is the unlock, everything else flows from that.

Now, here’s the brutal fact: 49% of exploited contracts get hit in the first 30 days, many in the first 7. Case-by-case subsidies simply don’t move fast enough. Even the most skilled teams got trapped in a 0-day attack by using Thirdweb/OpenZeppelin libraries. We wrote the detection query in 10 minutes and scanned tens of thousands of contracts in minutes. That’s what “infrastructure-first” looks like.

Arbiscan labels? Useful, but surface-level. Glider already tracks 150+ smart contract categories, and the number grows every month. This isn’t just for user convenience — it feeds the risk engine and DAO intelligence layer. List of labels is here: Glider Label Set.

With ~800 protocols on Arbitrum, most will never see individual subsidies, but with ecosystem-level integration, every single one benefits from day one.

That’s why this isn’t “fluff.” It’s about making Arbitrum the first chain to offer baseline, ecosystem-wide protection as a public good. Safer users, healthier projects, more transactions, more fees.

So here’s the real question: do we keep patching holes one by one, or do we set the standard for what blockchain security should look like?

[Federico]

Thanks for putting this forward. Security is obviously a top priority, and I agree that stronger tooling could add value.

That said, I’d like to see more evidence of Glider’s track record before committing such a large sum. The proposal mentions that over 90% of past Arbitrum exploits could have been caught with Glider. Can you share specific examples of how you would have detected and mitigated these vulnerabilities? Do you have a history of doing so elsewhere? A demo or case study would make it easier for the community to evaluate.

Adoption is another area that feels unclear to me. Who do you see as the main users, and how would this fit into their workflow? If the Security Council or other specific stakeholder groups are the target audience, it would be useful to hear directly from them whether this is something they actually need or would rely on.

Lastly, it’s not obvious why Glider should be funded as the only solution here instead of conducting an RFP process that includes other providers (TRM, Chainalysis, Range, Cipher Owl, etc.). If demand for this type of tooling is validated by key ecosystem stakeholders, an open process where multiple teams can present to the relevant AAEs would give the DAO a stronger basis for selecting the best solution.

[HaykK]

You’re raising exactly the right questions. Let me address them in turn.

Track record

Glider is already in active use outside of Arbitrum and is in testing phase with major CEXs, regulatory bodies, compliance analytics platforms, and wallets. Our team has a proven history in Web3 security as an approved audit provider. While many Glider findings remain private due to Rules and agreements with projects through responsible disclosure policies, some have resulted in over $1M in bounties for researchers.

Attached are a few case studies from these findings, as well as the Thirdweb 0-day incident, which may be especially relevant for the Security Council. Even when Glider was still in early development, we wrote a detection query in under 15 minutes and scanned tens of thousands of contracts instantly. That same query would have surfaced every vulnerable Arbitrum contract within minutes of disclosure.

Prevention of hacks

Glider works by formalizing vulnerabilities into query sets that scan for risky patterns across all contracts. Our analysis of two years of smart contract exploits shows that ~90% of vulnerabilities leading to hacks are queriable and would have been flagged by Glider (see attached “Hacks of Arbitrum protocols detectable by Glider _ 01.23-05.25”)

When a new 0-day exploit is discovered on ANY EVM CHAIN, we’ll create a query within 24 hours. Glider will scan all subscribed contracts and notify affected teams immediately.

The community-facing workflow is simple with 2 options:

1. We will provide platform, where any Arbitrum developer can subscribe free of charge by submitting their contracts and contact details. This way they will get instant notice, once Glider detects a bug in their code

2. Smart Contracts of those teams who haven’t subscribed, will still be in our DB and Glider will run on them. And again, whenever we will see a detection, we will try our best for identifying the team behind the code to responsibly disclose the bug. This way we ensure that every single smart contract is under Glider scanning

Meanwhile, the Security Council can use the Glider IDE and SOC dashboard for custom queries, real-time monitoring, and reporting on the chain’s overall security posture.

Adoption & users

Glider is designed for multiple layers of the ecosystem:

• Security Council & DAO → Security Operations Center dashboard + IDE, with visibility into vulnerabilities and trends to guide governance and subsidy decisions.
• Builders & protocols → 1-Day Protection, giving teams free alerts and self-checks without audit budgets.
• Users & researchers → labels on Arbiscan, plus API and screener access for quick token and contract risk scoring.

We’re not yet in direct touch with Security Council members but will ask moderators to facilitate introductions, as their perspective is critical. Adoption flows both top-down (DAO/SC oversight) and bottom-up (protocols/users via API).

Process (RFP vs. direct funding)

We understand the suggestion of an RFP. We submitted directly as an AIP because Glider is already production-ready and can be deployed to Arbitrum in weeks, not years. Our features (CFG/DFG-based labeling, 1-Day Protection, IDE, and SOC) are unique, and not offered by anyone, including analytics providers like TRM, Elliptic or Chainalysis, which focus on compliance/transaction intelligence rather than developer-centric contract security, risks and code level data.

That said, if the DAO prefers an RFP process, we’re open to participating and confident Glider’s technical depth and track record will stand out.

In short: this isn’t about funding one vendor, it’s about ensuring baseline, chain-wide protection as a public good. Glider is ready today, deployable quickly, and is the only one currently capable of delivering it.

P.S. Docs for Arbitrum - Google Drive here you may find documents of:
*- Thirdweb case

• Hack of Arbitrum protocols detectable by Glide
• Glider Case Studies*

[rpolysec]

This is a really thoughtful and compelling proposal, thanks for laying it out so clearly, Hayk.

I strongly support the idea of expanding access to high-quality security tooling like Glider for the broader Arbitrum ecosystem. As more protocols and independent developers build on-chain, having an accessible layer of proactive vulnerability detection feels essential to maintaining ecosystem integrity. The “1-Day Protection” and public-good framing really resonate, they bridge the gap between centralized oversight and grassroots security participation.

I also appreciate the focus on empowering builders and researchers, not just large protocols or institutions. Lowering the barrier to on-chain security work benefits everyone, from the DAO to end users.

While 1.5M ARB is a meaningful investment, it’s roughly equivalent to the annual cost of a small internal security team, and could easily pay for itself by preventing even a single significant exploit. More importantly, it can meaningfully reduce the time from discovering a vulnerability to identifying every other protocol potentially exposed through shared dependencies.

This is very different from integrating tools like Chainalysis or TRM, which are expensive, license-based, and primarily compliance-focused, and therefore out of reach for many independent researchers. Glider serves a distinct and much needed purpose in strengthening the open source security layer of the ecosystem.

Once the tooling is in place, hosting hackathons or bounties that leverage it could help drive adoption and empower a new wave of on-chain security researchers who might not otherwise have access to this level of infrastructure.

Excited to see this move forward and to learn how it integrates with existing DAO or Security Council monitoring frameworks.