Sec3

A recent major Solana exploit made the problem clear: not every protocol drain starts with buggy code. Some attacks rely on on-chain staging before execution: durable nonce activity and multisig governance changes. We added 3 free WatchTower monitoring bots for Solana protocols to detect that staging: • durable nonce account creation targeting your signers • nonce authority transfers to or from your signers • multisig config changes: threshold, timelock, members, config authority, rent collector Free for all Solana protocols: wt.sec3.dev/nonce/

If there are areas of the protocol where your team wants extra review, tell us early. That could be a new integration, a sensitive admin flow, complex accounting logic, or an assumption you want validated before launch. We will still review the full agreed scope. But knowing where the team wants deeper attention helps us allocate review time where it matters most.

A useful pre-audit exercise for Solana teams: Pick every CPI in the codebase and write down what your program assumes before and after the call. Before: - which program is being called? - which accounts are passed through? - which signer or writable privileges are being forwarded? After: - which balances or state fields must be rechecked? - which local assumptions could have changed? - what happens if the external program behaves unexpectedly? A CPI is not just a function call. It is a trust boundary.

Before a Solana audit, make an account map for each instruction. For every account, write down: - who owns it - who can sign for it - whether it must be writable - which PDA seeds derive it - which token mint or authority it depends on - how it relates to the other accounts in the instruction This does two things. It helps your team catch bad assumptions early, and it helps auditors spend less time reconstructing the account model from code.

The riskiest key in a Solana protocol is not always the upgrade authority. Sometimes it is the key that can change a market parameter, rotate an oracle, pause withdrawals, update fees, or move treasury funds. Before launch, teams should be able to answer a simple question: If this signer is compromised once, what can actually happen?

Vibe coding is cool. But when real funds are involved, users deserve more than vibes. DiversiFi has been audited by @ironnodesec and @sec3dev, because portfolio infrastructure should be built with safety, review, and clear risk boundaries from day one.

Just going to leave this here. github.com/helium/helium-… Circuit breaker contract, audited by @sec3dev. Highly recommend deploying your own copy of it with whatever security you're comfortable with. Or rewriting to fit your needs. Supports thresholds based on an absolute limit (IE 100 tokens in 24h) or by percentage of the account (IE 10% outflow in 12h). Rate limits transactions to the set threshold. We have monitoring on each circuit breaker that alerts at various percentages (before they're even tripped, so we can react if needed). Can wrap both mint authorities and token accounts.

For teams that want more detail, docs here: doc.sec3.dev/sec3-watchtowe…

A recent major Solana exploit made the problem clear: not every protocol drain starts with buggy code. Some attacks rely on on-chain staging before execution: durable nonce activity and multisig governance changes. We added 3 free WatchTower monitoring bots for Solana protocols to detect that staging: • durable nonce account creation targeting your signers • nonce authority transfers to or from your signers • multisig config changes: threshold, timelock, members, config authority, rent collector Free for all Solana protocols: wt.sec3.dev/nonce/

Lessons from the Drift Protocol Exploit - A Security Checklist for Solana Teams On April 1, Drift Protocol unfortunately experienced an approximately $285 million exploit. The attack surface was not code. It was governance configuration, key management, and operational trust assumptions. This is not a post-mortem of Drift. The facts are still developing and the team is actively responding. This is about what protocol teams should verify in their own deployments. What Happened The attacker gained access to multisig signer credentials through social engineering, then executed a staged operation over three phases: Infrastructure staging: a token was deployed with seeded liquidity to create the appearance of a legitimate asset. Durable nonce accounts were created on-chain (the first appearing 8 days before the exploit, the second one day prior), enabling pre-authorized transactions that could be triggered at a chosen time. Configuration change: the multisig was migrated to a new configuration that did not include a timelock on administrative actions. Execution: 31 withdrawal transactions drained three core vaults in approximately 12 minutes. Assets were bridged to Ethereum shortly after. What This Means for Other Protocols Each phase of this attack targeted operational and governance layers rather than smart contract logic. Any protocol with admin-controlled parameters, multisig governance, or privileged operations should consider whether similar vectors apply. What to Check Governance • Verify your multisig threshold and signer set. Confirm no unauthorized configuration changes have been made. • Confirm timelocks are enforced on non-emergency administrative operations (parameter changes, upgrades, configuration updates). Emergency stop functions can remain fast. • Monitor proposal creation, approval progression, and execution of privileged operations. Key Management • Confirm admin keys are secured via HSM or MPC with documented procedures around signing. • Scan for outstanding durable nonce accounts associated with your program authorities. Unrecognized nonce accounts warrant investigation. • Verify that any transaction using a durable nonce is fully expected and independently reviewed before signing. Operational Safeguards • Check whether withdrawal rate limits or circuit breakers make sense for your protocol's architecture. • Pre-establish contacts with bridge operators and exchanges for asset freeze coordination. Cross-chain fund movement during incidents moves faster than ad-hoc coordination. Takeaway Protocol security extends beyond code. Governance design, key management practices, and operational procedures are all part of the attack surface. Teams that proactively review these areas are better positioned to prevent and respond to this class of incident. If you have questions about your protocol's configuration or want help reviewing your security posture, reach out to us at contact@sec3.dev. - Sec3

Very important audit update for Splashing stakers. The Splashing Staking Contract has been audited with @sec3dev - and we’re happy to report 0 Critical and 0 High, which is already a great result. But that’s not all: 🔹Medium - 4 (resolved) 🔹Low - 5 (3 resolved / 2 acknowledged) 🔹Info - 2 (1 resolved / 1 acknowledged) This audit helped us harden security and refine how staking works. On top of that, if you have any questions, feel free to hop into our Discord server - we’ll be happy to answer them. We’re putting in every effort to make liquid staking as safe and user-friendly as possible for everyone. You’ll be able to find our audit report on our GitBook soon. Thank you, SEC3 🤝

The Token Metadata program is officially immutable. Three firms have each done a full audit of the program in sequence for security: @neodyme, @osec_io, and @sec3dev. With no more upgrade authority, assets created with the program are secured on Solana, forever.

We are excited to be heading to @SolanaConf soon! Most of our time at Sec3 is spent deep inside individual @Solana programs, looking at one code base at a time. To round out the year, we wanted to zoom out and ask a bigger question: What do all these audits, taken together, actually say about Solana security right now? Here’s what we saw: • Dataset: 163 Solana audits from a mix of public reports and anonymized Sec3 engagements • Findings: 1,733 total issues, 1,669 of them vulnerability-level • Typical review: ~10 findings, with ~1.4 High or Critical issues We also looked at how framework choices shape the risk as well as provide a practical guide projects launching and maintaining good security posture If you want to go deeper into the data, charts, and concrete checklists, the report is public: Web version + link to download full PDF: solanasec25.sec3.dev

AI agents exploited smart contracts worth $4.6mn in simulated attacks, with capabilities doubling every 1.3 months, but they still needed source code access. Non-public source code programs have some protection: AI reverse engineering exists but is far less capable than source code analysis. Though this gap will narrow. red.anthropic.com/2025/smart-con…

We’re proud to welcome @sec3dev as our Security Partner ! Sec3 will support our first cohorts with priority access to security expertise and guidance, helping early-stage teams build safer products on @solana. This collaboration strengthens our shared mission of empowering builders and supporting the ecosystem.

The Project 0 program code has been audited 11 times, & is one one of the most stress-tested DeFi protocols on Solana. The P0 risk & liquidity engine is built on @marginfi, which has handled +$100B in lends, borrows, withdrawals, & flashloans through all market conditions on Solana for 3 years while protecting user solvency.

@redacted_noah @sec3dev github.com/sec3-service/I…

why is @sec3dev 's IDL guesser not yet added in any of the explorer

@SteveCleanBrook @redacted_noah Thanks for the tag @SteveCleanBrook please feel free to reach out @redacted_noah if there are features you'd like us to add!

@redacted_noah Just use IDL guesser by @sec3dev

Programs that don't publish their IDL should be deleted from mainnet. Should I make the SIMD?

@orca_so 🦉 ❤️ 🐳

Orca 🤝 Owl Seeing the ongoing commitment to security with @sec3dev's team has been second to none. Our team is looking forward to working alongside Sec3 to keep security and trustworthiness a top priority.