.png)
We started 2025 in stealth. Early in the year, our focus was simple: build. We were working toward a specific goal of bringing real time, continuous security to teams building onchain. At the time, we were quietly building Octane and working with a small number of serious teams. Even in that limited setting, we were already finding vulnerabilities missed in manual audits and internal reviews, and even earning meaningful awards in audit contests. That was enough signal for us to know we were onto something, but not enough to rush it. In April, we came out of stealth.
What 2025 Taught Us About Automated Security for Smart Contracts (and More)
We started 2025 in stealth. Early in the year, our focus was simple: build. We were working toward a specific goal of bringing real time, continuous security to teams building onchain. At the time, we were quietly building Octane and working with a small number of serious teams. Even in that limited setting, we were already finding vulnerabilities missed in manual audits and internal reviews, and even earning meaningful awards in audit contests. That was enough signal for us to know we were onto something, but not enough to rush it. In April, we came out of stealth.
What changed after we started integrating with real ecosystems
We began integrating Octane with ecosystem partners that support larger builder communities, including Circle, Avalanche, and Plume. Once Octane was running inside real workflows, a few patterns started to emerge.
First, context mattered more than anything else.
The issues that surfaced were not obvious syntax errors. They were subtle, ecosystem specific problems tied to how protocols are designed to behave in the real world.
We saw this clearly with Circle. As USDC expands across wallets, protocols, and crosschain infrastructure, developers run into edge cases that are easy to miss, like blacklisted address reverts, decimal precision issues, or misuse of standards like EIP-2612 and EIP-712. Small implementation details can introduce real failure modes.
The same thing showed up on Avalanche and Plume. Detection became meaningfully more useful once Octane’s models were tuned to each ecosystem’s architecture, documentation, and usage patterns. High signal security depended less on scanning code in isolation and more on understanding how systems were actually supposed to work.
Second, the biggest impact showed up early.
The most valuable results were delivered before teams were thinking about audits or launch timelines. With Circle, Octane helped teams identify vulnerabilities in USDC related code before it reached production, including multiple high severity issues in a single review. On Plume, initial scans surfaced an insecure flow that could have led to loss of funds if deployed. By shifting security left, Plume ensured that it never got close to mainnet. On Avalanche, teams uncovered critical issues while they were still actively building, not weeks later during a last minute review.
When security runs inside CI/CD, timing changes. Fixes are faster, context is fresher, and fewer issues become real launch blockers.
Third, continuous security filled gaps that audits could not.
Several integrations surfaced high severity vulnerabilities in codebases that had already gone through manual audits. In one case, Octane identified a missing state update vulnerability in audited code that was about to go to mainnet. In others, issues were missed entirely or classified as low severity despite having meaningful real world impact.
This was not a failure of audits. It was a reminder of their limits.
What we saw again and again with security-first teams
Those ecosystem integrations were one side of the story. The other side was what we saw inside fast-moving product teams shipping every day.
We onboarded teams like Ostium, Superform, Covenant, Spark, and Button who needed security that kept up with how fast they were building.
At Covenant, deep cross contract interactions made it difficult for traditional audits to fully capture execution paths. When Octane analyzed audited code, it surfaced critical authorization and execution flaws that only became visible once call graphs and execution context were traced across contracts.
By the time Covenant began its audit contest, the codebase had gone through 80+ scans, resulting in 107 total fixes, including two critical vulnerabilities caught and remediated in real time.
Covenant budgeted a total of $43,000 for its audit contest. Since Octane had already caught the critical and high severity issues, the contest findings reported were all only informational.
Covenant’s final payout for the entire contest was just $1,600. Just $1,600. They saved $41,400 – that’s a lot of money!
At Superform, modular smart accounts, hooks, and cross chain flows created flexibility and with it, a larger surface area for subtle logic errors. At Ostium, perps markets required tight coordination between pricing, settlement, and access control logic, where even small gaps could cascade quickly.
As systems became more composable, security needed to reason across contracts, not just within them.
Even more importantly, security started changing how teams build.
Octane is integrated into multiple Spark codebases as the team builds out their onchain capital allocation platform. At Covenant, Octane runs on every pull request, surfacing issues immediately instead of weeks later through audit cycles. Superform embedded Octane directly into CI/CD so every new hook or module was analyzed before deployment. Ostium ran Octane on every commit, catching issues as code evolved instead of letting bugs accumulate. And Button’s final manual audit reported just one Medium severity issue that Octane had already flagged.
In each case, security stopped being something teams prepared for and became something they worked with continuously. Fixes happened earlier. Development velocity stayed intact.
How the product evolved alongside all of this
These experiences fed directly back into the product.
Over the year, we expanded full data flow analysis so models could reason better about how value moves across contracts. We added exploit scenario modeling to connect findings to how issues could actually be exploited. We made severity scoring transparent by grounding it as a function of impact and likelihood. And we continued reinforcement learning so detection improved as the system saw more real world examples.
As usage increased, so did results.
Over the course of the year, Octane surfaced a significantly higher volume of findings across teams and codebases.
The team also grew alongside the product. We started the year with four people and ended with fourteen, with most of that growth focused on engineering and security.
We launched Octane v3 in Q4, which brought language agnostic security analysis to entire protocol stacks, not just individual smart contracts.
We’re also looking forward to expanding the team further as demand and use cases continue to grow.
Heading into 2026
Looking back, 2025 clarified a few things.
- Continuous security fits naturally into modern development workflows.
- Combining automated detection with human review scales better than relying on one time checks.
- Teams building complex onchain systems need feedback early, while they still have time and bandwidth to act on it.
- There is real demand for Octane's continuous automated security for smart contracts and offchain infrastructure.
Heading into 2026, our focus stays the same.
We’re continuing to improve coverage, precision, and usability for teams that want security running alongside development. There’s more work ahead and plenty left to build.
We’re just getting started.