We’re excited to share that CypherTalk is now live on the DAO Security Fund.

Support here:
https://qf.giveth.io/project/cyphertalk-podcast:-security-education-for-ethereum?roundId=16

What is CypherTalk?

CypherTalk is a free, independent podcast focused on:

• Cybersecurity in Web3

• Privacy and operational security

• The human side of security failures

We translate complex security topics into practical insights for builders, users, and teams, so better decisions happen before things go wrong, ultimately reducing the risk of security failures and enhancing overall operational security.

Why this matters now

Crypto security isn’t just about smart contracts anymore.

A large share of losses today comes from the following:

• Phishing attacks

• Social engineering

• Weak operational security

• Human error under pressure

And with ecosystems growing faster and attackers becoming more sophisticated, these risks are increasing, not decreasing, which highlights the urgent need for improved security measures and proactive strategies to mitigate these threats.

Security education is one of the most scalable ways to reduce preventable losses, as it empowers individuals and organisations to recognise threats and respond effectively to security incidents.

What CypherTalk does

CypherTalk focuses on real-world security understanding, including:

• How attacks actually happen in practice

• How teams can improve operational security

• How users can avoid common traps

• Insights from leading experts in cryptography and Ethereum security

Featuring voices across the ecosystem, including:

• Griff Green (Giveth)

• Jordi Baylina (Zisk)

• Peter Kacherginsky (BlockThreat)

Why your support matters

CypherTalk is part of a quadratic funding round, meaning:

• Even small contributions matter

• Community participation increases matching

• More supporters = more funding unlocked

Your vote doesn’t just support a podcast; it helps fund security education for the entire Ethereum ecosystem.

Support CypherTalk

https://qf.giveth.io/project/cyphertalk-podcast:-security-education-for-ethereum?roundId=16

If Ethereum security matters to you, this campaign is one of the most direct ways to support it.

Every contribution helps strengthen the ecosystem’s ability to prevent the next major exploit, not just respond to it.

Thank you for supporting open security infrastructure.

Meet our senior team at Paris Blockchain Week (April 15-16) to harden your defences. Join our TG group to stay updated.

TheDAO Security Fund

Griff Green, founder of Giveth, shares lessons from the DAO hack, the evolution of Ethereum security, and how TheDAO Security Fund is pioneering community-led funding for crypto security on the latest episode of the CypherTalk podcast. Listen.

Featured audit: Reserve updates

Our team audited Reserve Protocol 4.2.0, looking at improvements in security and governance, and we have fixed all issues to maintain high standards. Read more.

Join our team!

Senior Blockchain Security Engineer | Job Posting Shared

Senior Zero-Knowledge (ZK) Blockchain Security Auditor (f/m/d) | Job Posting Shared

AI agents under threat

ClawJacked highlights the rising security risks of agentic AI, shows how vulnerabilities in cloud development environments can be exploited, and underscores the need for isolation, zero trust, and careful access control when running autonomous AI agents. Read more.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

The audit surfaced findings across informational and minor severity levels, all of which have since been acknowledged by the reserve protocol to ensure the programme meets strong security standards. Read the full auditreport.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We’ve entered the age of agentic AI, systems that don’t just think but act.

Modern AI agents can talk to APIs, call tools, move data, create sub-agents, and even perform tasks on behalf of users. Every new capability increases what these systems can do. But it also increases the number of ways attackers can exploit them.

A vulnerability known as ClawJacked offers a clear example of why the security risks around AI agents deserve closer attention.

A security weakness in cloud development environments

ClawJacked is a security weakness affecting certain browser-based cloud development environments. The issue stems from how authentication tokens are stored and accessed during active development sessions.

In a typical attack scenario, a developer visits a malicious website while logged into a vulnerable cloud development environment. Through carefully crafted cross-origin interactions, the attacker can trick the browser into leaking authentication tokens associated with the active development session.

Once these tokens are obtained, attackers may be able to:

• Access private source code repositories

• Interact with cloud APIs

• Modify development environments

• Potentially pivot into broader cloud infrastructure

The attack does not require installing software or malware. Instead, it relies entirely on browser session behaviours and token handling mechanisms, which can be exploited through techniques such as session hijacking or cross-site scripting.

In many ways, this vulnerability does not fundamentally change the threat model. Security professionals have long been sceptical about giving AI agents access to vast environments. However, ClawJacked highlights that many users are already doing exactly that and that it can quickly lead to serious trouble.

When AI agents have too much access

One of the core problems with AI agents is the amount of information they often have access to.

Agents frequently operate with large volumes of contextual data that are difficult for humans to fully oversee. At the same time, many users grant these systems far more privileges than they should.

As a result, an AI agent may have access to sensitive resources such as:

• API keys

• Login credentials

• Critical internal documents

• Access to financial systems such as bank accounts

If an attacker hijacks an agent with this level of access, the damage can extend far beyond the original system.

For example, if the agent has access to a user’s contact list or email history, a breach could place everyone in that network at risk. Past emails could also allow attackers to recreate the user’s writing style, making it easier to impersonate them and target colleagues, friends, or family members.

Safer ways to run AI agents

Because of these risks, running AI agent frameworks directly on personal or corporate machines is not recommended. AI agent frameworks are software systems designed to perform tasks autonomously using artificial intelligence.

Instead, systems like OpenClaw should be operated in controlled environments. One approach is to run them inside a Docker container on a separate server. This helps limit the damage if the agent or its environment becomes compromised.

Isolation and careful control over the environment are important steps toward reducing risk.

Using zero trust with AI agents

To secure these systems, many experts argue that organisations need to apply the Zero Trust principles.

The core idea behind Zero Trust is simple: never trust by default, always verify.

Instead of granting broad access “just in case,”, permissions should follow a just-in-time approach. Systems receive access only when it is needed and for the time it is required. This preserves the principle of least privilege, ensuring that entities only have the permissions necessary to perform specific tasks.

Another important shift is moving away from perimeter-based security. Rather than relying on a single protective boundary around a system, security controls should exist throughout the entire environment.

Perhaps the most important principle is the assumption of breach. Systems should be designed with the expectation that attackers may already be inside the network, database, or application. Security architecture should reflect that reality.

Treat autonomous agents as experimental

For now, organisations should treat fully autonomous AI agents, which are systems that can operate independently without human intervention, as experimental technology.

Companies should educate staff about the dangers of AI agents, particularly when it comes to permissions and access control. Excessive privileges granted to agents can pose significant security risks in the event of a system compromise, as they may allow unauthorised access to sensitive or critical systems, leading to potential data breaches or operational disruptions.

ClawJacked illustrates how seemingly small weaknesses can have large consequences when powerful automated systems are involved.

Agentic AI multiplies both power and risk. Zero Trust provides a framework for keeping that power under control.

Every agent must prove who it is, justify what it wants to access, and continuously earn trust. Only then can organisations safely harness the capabilities of autonomous systems without exposing them to potential attackers.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We will be at Cannes for EthCC, delving deeply into ZK, TEEs, FHE and privacy. Register now. We’ll also be hosting a surprise event like last year’s beachfront champagne tasting, all info in the TG group.

The future of ZK

The security legend Jordi Baylina talks to us about zero-knowledge technology and the future of privacy infrastructure on the latest episode of CypherTalk. Listen.

Peter Kacherginsky from BlockThreat joins us next to discuss threat modelling and the actual locations of exploits. Stay tuned.

2026, the year of institutions?

We debate whether crypto is becoming institutional infrastructure and what institutions actually need in terms of privacy on the latest episode of MetaMarkets. Listen.

Featured audit: Avail Cosmos and Backend Changes

During our audit of Cosmos and backend architecture changes for Avail, off-chain components became just as critical as smart contracts. Read more.

Join our team!

Senior Blockchain Security Engineer | Job Posting Shared

Senior Zero-Knowledge (ZK) Blockchain Security Auditor (f/m/d) | Job Posting Shared

Our custom AI translated a Solana Multisig to Stylus

If you are a Solana developer, try porting your contracts to Arbitrum. Read more.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We covered a broad surface area, encompassing the Cosmos SDK appchain, an off-chain node responsible for fulfilling bridging and settlement requests, and a TypeScript SDK.

The audit surfaced findings across critical, major, and minor severity levels. The resolved critical issues addressed serious vulnerabilities, including malicious vote extensions capable of mutating bridge state and consensus failures triggered by non-deterministic time checks. All resolved findings were verified by our team, and the remaining acknowledged issues represent risks the client has accepted or is actively tracking within their security model. Read the full audit report.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

The recent breach of Mexico’s government networks marks a chilling milestone: for the first time, a cybercriminal used an AI chatbot, Anthropic’s Claude, to orchestrate a large-scale attack. The attacker didn’t just access a single database; they extracted sensitive data across multiple agencies, including 195 million tax records, voter information, government employee credentials, and population registry files, totaling 150GB, according to Bloomberg.

What makes this data breach particularly notable is the level of insight it gives into the attacker’s mind and proficiency. Claude AI was able to retrieve most of the details of how the attacker engineered his attack; he prompted Claude AI in Spanish. While Claude initially warned the attacker about malicious intent, it eventually complied once the attacker claimed they were participating in a bug bounty program. Interestingly, the attacker also tried to obscure their intentions using OpenAI, a company known for its artificial intelligence technologies, but was ultimately blocked.

At Oak Security, we see this incident as an alarming trend. AI has made offensive hacking more accessible than ever, but AI systems still struggle to reliably detect and prevent malicious intent. They face a dilemma: limiting the tools’ offensive capabilities also reduces their defensive capabilities; that is what they advertise with.

Why this breach matters more than others

Even as AI evolves, the attack underscores persistent weaknesses in organisational security:

• Poor operational security practices

• Weak or missing authentication controls

Attackers using AI can scan, test, and exploit vulnerabilities much faster than before, so organisations must rethink cybersecurity as a proactive, adaptive discipline rather than a compliance exercise.

Our services to prevent AI-driven attacks

1. Operational security from scratch: Establish secure practices for all systems and workflows from day one. Book a training course.

2. Multiple-layered audits: Continuously harden products and infrastructure to detect vulnerabilities before attackers can exploit them. Request a quote.

The road ahead

AI will continue to reshape the threat landscape in the next 1-2 years. The Mexican government’s violations prove that no organization is immune. Security teams must recognise the dual nature of AI: it can empower both defence and offence. The time to prepare is now.

For a deeper dive into immediate actions enterprises and government bodies should take to protect sensitive data, see our follow-up article.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

The recent Claude AI breach of Mexican government networks has demonstrated a new reality: AI is enabling attackers to scale their operations and craft sophisticated attacks faster than ever. Enterprises and government bodies can no longer rely solely on traditional security measures. Protecting sensitive data now requires a proactive, holistic approach.

1. Implement and enforce zero trust architecture (ZTA)

Zero Trust operates on a simple principle: never trust. Every system, communication, and user is treated as potentially compromised. Key aspects include:

• Least-privilege access: Employees, contractors, and even executives should only have access to systems and data necessary for their role.

• Formal frameworks: Follow standards like NIST SP 800-207, which provides a global benchmark for designing secure architectures.

A Zero Trust setup ensures that even if credentials are stolen or an employee is compromised, attackers cannot move freely within the network.

2. Enforce phishing-resistant multi-factor authentication (MFA).

Passwords alone are no longer sufficient. Organisations must deploy strong authentication methods to protect critical systems:

• Hardware keys: Physical devices like YubiKeys provide strong protection against phishing and credential theft.

• Passkeys and authenticator apps: Public/private key-based solutions and OTP apps add layers of security, reducing risks from stolen passwords.

3. Continuous monitoring and behavioural analytics

AI-powered attacks can move quickly, often bypassing traditional alerts. Continuous monitoring of network and user behaviour allows organisations to detect anomalies in real time and respond before breaches escalate.

4. Encrypt data at rest and in transit.

Encryption ensures that even if attackers gain access to systems, the information remains unreadable and unusable. This includes sensitive tax, voter, and employee data in government systems, as well as proprietary business data in enterprises.

The bottom line

The Claude AI incident is a warning: attacks are evolving, and AI can empower even lone attackers. Enterprises and government bodies must assume breaches are inevitable and design systems that minimise impact. Implementing Zero Trust, strong authentication, continuous monitoring, and encryption is no longer optional; it’s essential for safeguarding sensitive data in a world of AI-driven threats.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We built StylusPort to close that gap: an open-source MCP server paired with a 13-chapter migration handbook for Solana-to-Stylus work.

Stylus port has the power to overcome what separates Solana and the EVM: The execution and data models of Solana and Stylus diverge in critical ways: Solana accounts vs EVM storage, PDAs vs contract addresses, Borsh vs ABI encoding, CPI vs external calls, and compute units vs gas.

We equipped Claude Opus 4.6 with StylusPort and ported a Solana Multisig to Stylus. The input was Coral’s production multisig program (roughly 300 lines of Anchor Rust). The output was a Stylus contract implementation with 23 unit tests.

Read below what worked, what failed, and what still needs human review. The short version: structured retrieval and constrained workflows produce a strong starting point, but they do not replace audit-grade engineering.

ℹFor readers unfamiliar with MCP: Model Context Protocol is an open standard that lets AI assistants use external tools and knowledge.

What is StylusPort?

StylusPort has three components.

The Handbook. Thirteen mdbook chapters covering migration patterns: program structure, state storage, access control, external calls, native tokens, ERC20/721, errors and events, a full Bonafida Token Vesting case study, testing/debugging, gas optimization, and security. Each chapter includes side-by-side Solana and Stylus examples in both Anchor and “Native” flavors.

The MCP Server. A Rust binary exposing four tools, thirteen resources, and two prompts over stdio. It works with Claude Code, Cursor, OpenCode, and other MCP-compatible harnesses.

The Prompts. Two structured workflows with defined steps:

• Plan --- analyze the Solana program, search the handbook, then produce an 11-section migration plan with architecture mapping tables, a risk register (minimum eight items), implementation phases, and a test plan.

• Execute --- read the plan, implement phase by phase, verify WASM compilation, run tests, and produce a completion summary.

The four tools

• detect_solana_program_kind --- reads a Cargo.toml and returns “anchor” or “native” to determine migration strategy.

• search_handbook --- BM25 full-text search across all 13 chapters, returning ranked resource URIs.

• generate_stylus_contract_cargo_manifest --- produces a Cargo.toml with pinned dependencies (stylus-sdk = “=0.9.0”, alloy-primitives = “=0.8.20”, motsu = “0.10.0”), WASM target config, and release optimizations.

• generate_stylus_contract_main_rs --- produces the ABI export entrypoint boilerplate.

The target: Coral Multisig

Coral (formerly Serum) Multisig is a production Solana governance contract. It is compact (about 300 lines in one lib.rs) but still exercises migration-critical patterns.

It implements an M-of-N multisig wallet. A group of owners collectively approve and execute arbitrary Solana transactions. The key concepts:

• Multisig account: owners list, approval threshold, and an owner_set_seqno (a version counter that invalidates all pending transactions whenever the owner set changes).

• Transaction account: target program, instruction data, an approval bitmap tracking which owners have signed, and a did_execute flag preventing replay.

• PDA signer: a Program Derived Address that signs for cross-program invocations during execution.

• Self-governance: set_owners and change_threshold can only be called through the multisig’s own execute_transaction, creating a recursive self-call pattern.

It uses Anchor, multiple related account types, CPI with PDA signing, layered access control, and state invalidation logic, while remaining small enough to verify by hand.

The migration in two commands

Step 1: plan

We invoked the Plan prompt inside Claude Code.

Discovery: Claude scanned for Cargo.toml, read programs/multisig/src/lib.rs, then ran detect_solana_program_kind and got “anchor”, which routes it to the Anchor-flavored handbook sections.

Handbook research: Five parallel search_handbook calls followed; each returned a ranked list of chapters to read.

• “storage state accounts mapping Solana to Stylus”

• “access control authorization signers owners”

• “CPI external calls cross-program invocation”

• “serialization data layout borsh anchor”

• “errors events logging revert”

Note: targeted search helps avoid context-window overload, which can reduce output quality.

Then it read seven handbook chapters via their MCP resource URIs: state-storage, access-control, external-calls, errors-events, security-considerations, testing-debugging, and program-structure.

Boilerplate generation: Both generators were called to produce a Cargo.toml and main.rs with pinned dependency versions.

Compared with ad hoc prompting (or Skills alone), the MCP server reduces unnecessary non-determinism by generating standardized boilerplate.

Plan output: Claude wrote a 551-line plan.md covering all eleven required sections. Key sections included:

The architecture mapping tables captured how each Solana account type becomes Stylus contract storage:

The risk register identified ten risks with concrete mitigations:

• Reentrancy. Solana’s runtime prevents reentrancy by default. The EVM does not. Mitigation: set did_execute = true before the external call (checks-effects-interactions pattern).

• Owner index drift. If the owner set changes between transaction creation and execution, signer indices become meaningless. Mitigation: the owner_set_seqno mechanism, carried over directly from the Solana implementation.

• Self-call authorization. Solana uses PDA signing. Stylus needs msg_sender() == contract_address(). Governance functions must be unreachable from external callers.

You can see the generated plan in its entirety here.

Step 2: execute

We invoked the Execute prompt. Claude read the plan and began implementing it phase by phase.

Phase 1 - Project Setup: Created Cargo.toml, src/main.rs, and a src/lib.rs skeleton. The first WASM build failed with a missing vec! macro. In no_std, vec! comes from alloc, not the standard prelude. Claude added extern crate alloc; use alloc::vec; and rebuilt successfully.

Note: this shows a guess-then-retrieve loop. If a wrong guess compiles, the error can still slip through.

Phase 2 - Storage and Errors: Defined all storage types, eleven error variants, and six events using the sol! macro. The WASM build passed with warnings about unused fields.

This is where the error model becomes more expressive than the original. Anchor errors are essentially u32 codes with string messages:

#[error_code]
pub enum ErrorCode {
    #[msg("The given owner is not part of this multisig.")]
    InvalidOwner,
    // ...
    #[msg("Not enough owners signed this transaction.")]
    NotEnoughSigners,
    // ...
    #[msg("The given transaction has already been executed.")]
    AlreadyExecuted,
    // ...
}

The Stylus version carries structured data:

sol! {
    error InvalidOwner(address caller);
    error NotEnoughSigners(uint64 required, uint64 provided);
    error AlreadyExecuted(uint256 tx_id);
    // ...
}

#[derive(SolidityError)]
pub enum ContractError {
    InvalidOwner(InvalidOwner),
    NotEnoughSigners(NotEnoughSigners),
    AlreadyExecuted(AlreadyExecuted),
    // ...
}

Clients can now programmatically read which owner was invalid and how many signatures were missing, not just that an error occurred.

Phase 3 - Core Logic: Claude implemented all seven public functions, seven view functions, and seven internal helpers. Two compile issues required API and import adjustments.

First: error[E0277]: the trait bound ‘alloy_primitives::Bytes: AbiType’ is not satisfied. The Bytes type is not ABI-encodable in the Stylus SDK. Claude switched the public API signatures from Bytes to Vec<u8>.

Second: error[E0433]: could not find ‘calls’ in ‘stylus_sdk’. The import path for the Call context had changed between SDK versions. Claude re-consulted the handbook’s external-calls chapter and found the correct path: stylus_sdk::prelude::*.

After the adjustments, the ported contract’s public interface looks like this:

#[public]
impl Multisig {
    #[constructor]
    pub fn constructor(&mut self, owners: Vec<Address>, threshold: U64) { // ... }
    pub fn create_transaction(&mut self, target: Address, value: U256, data: Vec<u8>) -> Result<U256, ContractError> { // ... }
    pub fn approve(&mut self, tx_id: U256) -> Result<(), ContractError> { // ... }
    pub fn execute_transaction(&mut self, tx_id: U256) -> Result<Vec<u8>, ContractError> { // ... }
    pub fn set_owners(&mut self, owners: Vec<Address>) -> Result<(), ContractError> { // ... }
    pub fn change_threshold(&mut self, threshold: U64) -> Result<(), ContractError> { // ... }
    pub fn set_owners_and_change_threshold(&mut self, owners: Vec<Address>, threshold: U64) -> Result<(), ContractError> { // ... }

    // View functions
    pub fn get_owners(&self) -> Vec<Address> { // ... }
    pub fn get_threshold(&self) -> U64 { // ... }
    pub fn get_transaction(&self, tx_id: U256) -> (Address, U256, Vec<u8>, Vec<bool>, bool, U32) { // ... }
    pub fn is_owner(&self, addr: Address) -> bool { // ... }
    pub fn get_tx_count(&self) -> U256 { // ... }
    pub fn get_owner_set_seqno(&self) -> U32 { // ... }
    pub fn get_approval_count(&self, tx_id: U256) -> U64 { // ... }
}

Phase 4 - Unit Tests: Twenty-three tests using the motsu harness by OpenZeppelin. They cover constructor validation, transaction creation, approval flow, execution guards, owner-management authorization, view functions, and property invariants. All pass, but what exactly was tested?

The tests break down into seven categories: constructor validation (6 tests covering valid init, single owner, empty owners, zero threshold, threshold exceeding owner count, and duplicate owners), transaction creation (4 tests: success, auto-approval by creator, ID increment, non-owner rejection), approval flow (4 tests: success, non-owner rejection, double-approval rejection, invalid transaction rejection), execution guards (2 tests: insufficient signers, invalid transaction), owner management authorization (3 tests: set_owners, change_threshold, and set_owners_and_change_threshold all rejected when called directly), view functions (2 tests: is_owner and get_transaction for a nonexistent ID), and property invariants (2 tests: threshold bounds and approval count not exceeding owner count).

This is decent coverage of the rejection paths, but it has significant gaps.

No successful execution test: execute_transaction is only tested for failure cases. There is no test that a fully-approved transaction actually executes and returns the expected result. The entire happy path of the contract’s core function is untested.

No self-governance test: The three owner-management tests only verify that direct calls are rejected. The happy path --- calling set_owners or change_threshold through execute_transaction --- is never tested. This is the contract’s most critical flow: the re-entrant self-administration pattern where the multisig governs itself by executing transactions that target its own functions. An auditor would flag this immediately.

No owner_set_seqno invalidation test: The stale-seqno rejection path, where an owner-set change invalidates pending transactions, is untested. This is a security-critical invariant carried over from the Solana implementation.

No AlreadyExecuted test: The replay-protection path, where a second execution of the same transaction is rejected, is untested.

Key migration patterns

Four patterns from this migration recur across Solana-to-Stylus ports.

Accounts become contract storage

Solana stores each piece of state in a separate, dedicated account. Stylus stores everything inside the contract.

Solana:

#[account]
pub struct Multisig {
    pub owners: Vec<Pubkey>,
    pub threshold: u64,
    pub nonce: u8,
    pub owner_set_seqno: u32,
}

#[account]
pub struct Transaction {
    pub multisig: Pubkey,
    pub program_id: Pubkey,
    pub accounts: Vec<TransactionAccount>,
    pub data: Vec<u8>,
    pub signers: Vec<bool>,
    pub did_execute: bool,
    pub owner_set_seqno: u32,
}

Stylus:

#[storage]
pub struct Transaction {
    target: StorageAddress,
    value: StorageU256,
    data: StorageBytes,
    signers: StorageVec<StorageBool>,
    did_execute: StorageBool,
    owner_set_seqno: StorageU32,
}

#[storage]
#[entrypoint]
pub struct Multisig {
    owners: StorageVec<StorageAddress>,
    threshold: StorageU64,
    owner_set_seqno: StorageU32,
    tx_count: StorageU256,
    transactions: StorageMap<U256, Transaction>,
}

Key shifts: Pubkey becomes Address, Vec<T> becomes StorageVec<StorageT>, and separate Transaction accounts collapse into StorageMap<U256, Transaction>. The nonce disappears (no PDA derivation in EVM), while tx_count is added as an explicit identifier counter.

PDA signers become the contract address

On Solana, the multisig executes transactions by deriving a PDA and using it to sign a cross-program invocation:

let multisig_key = ctx.accounts.multisig.key();
let seeds = &[multisig_key.as_ref(), &[ctx.accounts.multisig.nonce]];
let signer = &[&seeds[..]];
solana_program::program::invoke_signed(&ix, accounts, signer)?;

On Stylus, the contract is the signer. When it makes an external call, msg.sender on the receiving end is the contract's own address:

let call_context = Call::new().value(value);
let result = self.vm().call(&call_context, target, &data);

This simplifies the self-governance pattern. On Solana, set_owners requires a PDA signer account derived from specific seeds, validated through Anchor constraints. On Stylus, it is a four-line check:

fn require_self_call(&self) -> Result<(), ContractError> {
    if self.vm().msg_sender() != self.vm().contract_address() {
        return Err(ContractError::Unauthorized(Unauthorized {}));
    }
    Ok(())
}

Errors get richer

Anchor errors are essentially u32 codes with human-readable messages attached at compile time. A client learns that “not enough owners signed” but not how many did sign or how many were needed.

Stylus errors, defined through the sol! macro, carry structured data:

error NotEnoughSigners(uint64 required, uint64 provided);

This improves off-chain diagnostics. Tooling can programmatically parse the error, display the gap, and help users understand exactly what went wrong.

Why structured knowledge matters

A simpler experiment is to ask an LLM to “port this to Stylus.” The result can look plausible while missing runtime-critical differences like reentrancy assumptions, storage semantics, or ABI constraints.

StylusPort improves this with retrieval plus constrained prompts: research first, implementation second, and an explicit plan with risk analysis and architecture mapping.

The two-phase workflow also creates a practical review gate: inspect the migration plan, challenge architectural choices, and correct direction before implementation.

That division of labor matches the principle we discussed before: the model accelerates boilerplate and pattern transfer, while humans validate design and audit correctness.

Conclusion

Structured knowledge plus AI execution can produce a reliable migration starting point. Here, the plan was reviewable, the generated contract compiled, and tests covered many rejection paths. What remains is the hardest work: auditing correctness, testing realistic execution paths, and validating security invariants under deployment conditions.

Your mileage may vary

Coral Multisig is a single-program, 300-line repository. Real-world Solana projects are often multi-program monorepos with shared state, internal CPIs, and dense account relationship graphs. As complexity rises, omission risk rises with it.

The practical value of this tooling is speed-to-first-working-draft, not automatic correctness. Treat generated code as a starting point that still needs disciplined review, comprehensive testing, and security audit.

For MCP server setup instructions and the latest workflow details, refer to the StylusPort repository.

The handbook is also available to read online. In addition to practical porting guidelines, it also covers the differences between Solana programs and Stylus contracts, as well as security considerations.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We’re heading to Hong Kong for Consensus HK (Feb 10-12), where we’ll focus on institutional scaling and enterprise-grade security.

The enemy isn’t just code

Social engineering continues to be the top threat to crypto teams. We explain why attackers keep winning and how strong OpSec and zero-trust practices can dramatically reduce risk. Read more

Think your Web3 assets are safe?

Join our free OpSec session on Feb 26, 5 PM CET, and learn how hackers really strike and how to stop them!

Cyphertalk Podcast is live!

Our new twice-monthly podcast on real-world cybersecurity and privacy, kicking off with Security & Privacy in 2026, covering human risk, AI-driven threats, zero-knowledge tech, and what actually keeps systems resilient. Listen here

CoinList Token Sale Fund

We recently audited the CoinList Token Sale Fund, reviewing custodial smart contracts, backend flows, and security controls. We addressed all critical issues and received praise from CoinList for our partnership. Read more

Join our team!

Senior Blockchain Security Engineer | Job Posting Shared

Senior Zero-Knowledge (ZK) Blockchain Security Auditor (f/m/d) | Job Posting Shared

TGE security, done right

Launching a token? Don’t rely on hope or audit badges. Our latest guide offers a practical checklist for Token Generating Events (TGEs), covering layered security, early detection, and rapid incident response. Read more

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

The system relies on role-based access control to separate committing, remitting, and ownership responsibilities, and is designed to support ERC-20 token contributions under strict operational assumptions. It incorporates internal accounting of committed and remitted balances, and administrative controls for managing privileged roles and final fund transfers.

In addition to the code review, we conducted a full threat modeling exercise covering on-chain contracts, backend systems, privileged operators, and external token dependencies.

During the audit, we identified several minor and informational issues related to trust assumptions, operational edge cases, and best practices. All resolved issues were fixed and verified, while the remaining findings were acknowledged by CoinList as acceptable within their security and governance model. Read the full audit report.

“Oak Security has been a great partner from day 1. They are very flexible, always open to communication, and able to support all our needs. Highly recommend them.”- Matt Delacour, CTO, CoinList

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

We’re excited to announce the launch of Cyphertalk, a twice-monthly podcast exploring the realities of cybersecurity and privacy in a world that’s moving faster than our defenses.

In Episode 1: Security and Privacy in 2026, hosts Jade Doherty and Stefan Beyer (co-founder of Oak Security) dive into:

• Why humans are the #1 target: phishing, social engineering, supply chain attacks

• Remote work, context switching, and why “always-on” makes mistakes more likely

• AI as an arms race: scaling attacks vs improving defenses

• ZK/privacy tech maturity: new opportunities and new risks

• Why the “zero trust mindset” is about reducing impact, not paranoia

• Institutional security expectations and how crypto security is (slowly) evolving

Stefan also shares a personal story of a highly targeted “podcast invite” scam that nearly turned into a credential-stealing attack, a perfect example of why, in 2026, it’s less about never making mistakes and more about designing systems that limit blast radius when mistakes happen.

Listen & Subscribe:
🎧 Podbean
Apple | Spotify

We’d love your feedback! Follow, subscribe, leave a review, or send us your topic suggestions, we want Cypher Talk to cover what you really want to know.

Stay safe, stay curious,
Oak Security

Web3 projects consistently demonstrate a strong commitment to cybersecurity. Many protocols invest heavily in security reviews, engage reputable audit firms, and communicate their efforts transparently to users and investors. This reflects a shared understanding: security matters.

Yet recent high-profile incidents reveal that investment alone is not enough. Audits are more common than ever, but their effectiveness depends on how they are scoped, structured, and executed. The 2025 Balancer exploit offers a clear lesson. Despite multiple audits that deemed the protocol mature and secure, a vulnerability outside the defined audit scope was exploited, leading to losses of A. They performed the reviews exactly as specified. The key takeaway is that clearly defining the scope of security work is just as important as the quality of its execution.

The problem with cybersecurity RFPs

A Request for Proposals (RFP) is the document a project uses to engage a cybersecurity firm. It specifies:

• Which systems or codebases will be reviewed

• The depth and methodology of the review

• What is included in and excluded from the scope

• The expected deliverables

RFP defines a project’s security priorities. What is included signals which risks are considered most critical, while what is excluded reflects assumptions about acceptable or unlikely threats.

The problem is RFPs themselves require expert knowledge. Scoping a review is a security-relevant task. Ideally, scoping should involve a third-party expert. If the scope is incomplete, audits may leave critical risks uncovered. Often, RFPs are unclear, leaving auditors narrowing the scope further to submit competitive bids. This creates a race to the bottom, where security is optimised for cost rather than real-world risk coverage.

Current audit platforms reinforce this mindset. They are optimised for conducting audits, which encourages projects to treat security as an afterthought. Cybersecurity RFPs are conducted after development is completed, which violates the shift-left paradigm.

Why audits benefit from clearer framing

In many industries, certifications serve as indicators of safety. Web3 often adopts a similar mindset, treating audit reports as proof of security.

Audits are highly valuable, but they are limited to the scope of a specific engagement. Auditors focus on the tasks assigned to them, which can be a strength as long as the scope encompasses all relevant risks. Poorly scoped audits, even if executed flawlessly, can give a false sense of security. Clear, thoughtful framing of security objectives ensures audits deliver real-world protection rather than just a report.

Advancing the RFP process

When used intentionally, RFPs remain one of the most effective tools for commissioning security but only if carried out by experts and early in the development cycle:

• Engage security expertise early
  Before soliciting proposals, internal security leads, virtual CISOs, or external advisors can assist in defining the scope.

• Separate scoping from execution
  A neutral expert can design the RFP and evaluate bids, allowing auditors to focus on delivery while improving coverage.

• Evolve audit platforms
  Supporting adversarial testing, follow-up reviews, and remediation leads to stronger, longer-lasting outcomes.

• Emphasise outcomes over checklists
  Outcome-driven security aligns incentives around resilience, risk reduction, and user protection.

Security as a continuous discipline

Web3 does not suffer from a lack of audits. It has an opportunity to better align security investment with security outcomes. By refining how security work is defined and commissioned, the industry can:

• Set clearer expectations

• Improve collaboration between teams and auditors

• Build more resilient systems

In cybersecurity, outcomes are shaped early. When projects ask better questions, they receive better protection.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

A Token Generating Event (TGE) is when a protocol’s token goes live and becomes tradable. It enters the financial world.

Before TGE, the financial damage is limited. After TGE, real money, real users, and real attackers appear simultaneously. Incentives change. Liquidity increases. Mistakes become hard or impossible to undo.

Successful launches are rarely defined by one technical choice. They depend on whether security was treated as an ongoing process, not a final checkbox.

A secure TGE starts with a simple assumption: what can go wrong will go wrong. In a perfect world, there are no mistakes. In practice, you have to plan for failure. The goal is to detect problems early, understand them quickly, and limit their impact.

Security assurance and incident preparedness

Security assurance and incident preparedness focus on two things:

• Reducing the chances of exploitation

• Making sure the team can respond quickly and clearly when issues arise

At TGE, the security team must simultaneously limit how the protocol can be attacked and ensure a quick response to issues.

1. Limit how the protocol can be attacked

2. Enable fast detection, decision-making, and response

This requires security to cover the entire system. It must include design, development, deployment, and live operations. A final audit alone is not enough. If prevention or response is missing, small issues can quickly escalate into serious incidents once economic incentives are in place.

Security is a lifecycle process

Security is not a single tool or approval. It is a set of controls applied throughout the protocol’s lifecycle.

Each control helps, but none are perfect. By applying protections across Design→ Development → Release→ Operation, teams avoid relying on a single line of defence.

The most effective security work happens early. Issues found during design or development are easier and cheaper to fix. Controls in production exist to detect and contain problems that still occur after launch.

This approach assumes mistakes will happen. It is built to handle them.

No single control is enough on its own. Using multiple layers ensures problems are caught early and contained before they escalate. Read more on the “Swiss Cheese Model” of Cybersecurity.

TGE security readiness checklist

Principles are not enough. Teams need a practical checklist.

The TGE security readiness checklist turns this lifecycle approach into clear tasks. It is intended for use in the weeks before TGE as a working document, not a one-time review.

The checklist covers:

• Architecture and documentation accuracy

• Threat modelling and safety procedures

• Upgrade mechanisms and emergency controls

• Monitoring across contracts, infrastructure, and markets

• Team access controls and security practices

• Testing depth and coverage

• Audit, pentesting, and bug bounty readiness

• Launch-day incident planning and escalation

The checklist is available as a downloadable PDF, allowing teams to track ownership, progress, and readiness.

Download the security assurance & incident preparedness checklist to include it in your TGE plan.

Deliverables and support

The protocol team is responsible for core security work, including:

• Testing

• Documentation (Web2, Web3, and other components e.g. access to banking, etc.)

• Security Architecture

Oak Security supports teams before and during TGE with both strategic and hands-on security services. This includes:

• Security Strategy, including vendor selection

• Threat models, audits, operational security training

• Virtual CISO Services

• Operational Security Support

• Incident response runbook and escalation tree

For higher-risk launches, additional support may include:

• Launch-day war room plan - technical & market incidents

• Incident response team

• Monitoring solutions setup

• Physical security training/inspection of offices

The protocol team typically coordinates these efforts, with Oak providing guidance and oversight.

A secure TGE depends on three things: clear ownership, layered security, and rapid response. Getting these right before launch is what keeps small issues from becoming major incidents.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

gmgm, the $4 billion wake-up call

While the culture is shifting toward utility, the threats have scaled to a terrifying level. 2025 was the most devastating year on record for digital theft, as nearly four billion dollars in crypto assets were stolen. Over 50% of these losses were caused by state actors such as the North Korean Lazarus group, targeting the OpSec Achilles’ Heel.

Our 2026 security predictions: The AI offensive

In 2026, the battlefront is moving from the code to the user.

• AI-Enhanced Social Engineering: Attackers are using LLMs to generate voice clones and hyper-personalized phishing campaigns.

• The “Vibe Coding” Debt: AI assistants allow for rapid shipping, but “vibe coding” increases the attack surface. Also, it is more susceptible to introducing outdated, vulnerable dependencies. We expect 2026 to be the year of the AI-driven supply-chain attack.

Don’t get rekt: Invest in Operational Security and build a security-first culture

We offer an Operational Security course for Web3 teams that addresses the most critical security threats in the ecosystem, emphasizing quality over quantity with real-world examples and actionable takeaways. The training starts at $5000 for a full team.

We are here to fight those trends with our 2026 Security Strategy Sessions

Meet our senior team to harden your defenses.

• Buidl Lisbon | Jan 7–8 | Focus: Personal Security

• Consensus HK | Feb 10–12 | Focus: Institutional Scaling

• EthCC[9] Cannes | Mar 30–Apr 2 | Focus: ZK-Primitives & Privacy

• Paris Blockchain Week | Apr 15–16 | Focus: Compliance & RWA

• Consensus Miami | May 5–7 | Focus: State-Sponsored Defense

• Devcon 8 Mumbai | Nov 3–6 | Focus: Securing the Next Billion

Want to partner for an event? Write to us at info@oaksecurity.io

We’re hiring: ZK auditors

We are looking for elite ZK Researchers to help us build the privacy primitives that will define the next decade of finance. If you live at the intersection of math and security, [Apply here].

AI is reshaping software development, and Web3 isn’t an exception. Developers are writing smart contracts faster than ever, using AI. Some developers are now 5–10× more productive thanks to AI. That speed is exciting, but it also brings new risks.

The vibe coding trend

We increasingly see AI-generated (“Vibe-coded”) code that:

• Is complex, but the team doesn’t fully understand

• Has “perfect” test coverage that checks nothing meaningful

• Misses invariants and edge cases

• Feels bloated without functional purpose

More code. Less understanding. This complicates security reviews.

AI can audit code, but its capabilities are limited.

Although single shot prompting of ChatGPT and other LLMs are able to detect vulnerabilities, the usual outcomes are:

• ~40% precision → 6 out of 10 findings are false positives.

• ~40% recall → misses 6 out of 10 real vulnerabilities.

Better setups, multi-agent or ML-based, can reach >90% precision and recall.

AI is excellent at identifying known patterns but poor at new or complex logic.
Example: a model flagged a reentrancy bug but missed a cross-chain MEV exploit nearby.

AI only detects what’s in its training data; novel exploits need human insight. Similarly, AI today is excellent at routine, recognisable vulnerabilities, but not complex, protocol-level logic that requires economics, game theory, or multi-protocol reasoning.

How we use AI at Oak Security

AI is already a core part of our workflow:

• Detecting common bugs

• Summarising large codebases

• Automating fuzzing setups

• Generating proof of concepts

• Speeding up documentation and reporting

• Eliminating repetitive tasks

AI handles the noise, while humans focus on novel and critical vulnerabilities. It doesn’t replace auditors; it supercharges them.

How to use AI safely in smart contract audits

1. Use AI for high-coverage, low-risk tasks.

• Pattern detection

• Code summarisation

• Auto-documentation

• Test generation

• Fuzzing scaffolds

2. Keep humans in the loop for anything requiring reasoning.

• Protocol logic review

• Economic/game-theoretic analysis

• Cross-chain interactions

• Attack-surface mapping

• Novel exploit discovery

3. Never trust a single AI output.

• Run multi-agent or ensemble models where possible

• Validate everything manually

• Treat AI findings as suggestions, not truths

4. Protect your private code.

• Use local open-source models

• Avoid sending sensitive code to cloud LLMs

• Keep logs, prompts, and outputs internally

5. Combine three pillars of security

• AI for speed and coverage

• Human auditors for complexity, creativity, and novel exploits

• A zero-trust security mindset across the entire team

Equip auditors; don’t replace them. That’s how we build safer protocols and a safer ecosystem.

The future: humans × AI.

AI is best at patterns, boilerplate, and speed. Humans excel at economic reasoning, game theory, complex logic, and novel exploits.

Together, they’re stronger than either alone.

Want to Level Up Your Team’s OpSec?

We run a free Web3 Security Awareness Training for technical and non-technical teams. Register.

It covers:

• Team behaviour

• Key management

• Phishing and device compromise

• Practical ways to avoid exploits

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

At 5pm CET today, we’re hosting a free, live Operational Security course for Web3 teams that covers not only how projects get compromised, but how individuals can lose their personal wealth too.

Who should join?

Anyone working in Web3: devs, founders, PMs, BD, marketing, community, and execs.

This is a live and interaction session with Oak Security co-founder, Dr. Stefan Beyer, who has worked on distributed systems and cybersecurity for 20+ years.

In this short session, we’ll cover:

• The OPSEC failures attackers exploit in Web3 right now

• How social engineering actually works and the red flags most teams miss

• Simple frameworks and checklists to avoid becoming the next headline

• OPSEC habits you can use immediately, at work and in your personal life

If you build in Web3 or hold meaningful crypto, this is worth your time.

🕒 Today at 17:00 CET

🎟️ Register here by 16:00 CET

Security spending in Web3 is at an all-time high, yet losses are too. Projects lost over $2B in the first half of 2025, despite being more audited than ever. Clearly, something is missing.

It’s not that auditors are failing. It’s that audits were never meant to define safety; they validate it. Treating an audit as a guarantee is a common mistake, and one that keeps repeating.

Most exploits are not caused by exotic bugs; rather, they result from poor decisions.

• Misconfigured privileges

• Rushed deployments

• Unreviewed internal changes

• Faulty assumptions about control

• Key management that fails at the worst time

• Unaudited code that is pushed to production

These are not just code problems. They are leadership and operational problems.

Web3 is missing someone who actually owns security.

Shared responsibility without leadership becomes no responsibility. A Chief Information Security Officer, or CISO, fills this role in traditional Web2 organisations. A CISO is empowered to say:

“This design creates unacceptable risk.”
“This is not ready for production, including mainnet.”
“This workflow will eventually compromise keys.”

Web3 teams rarely have this role. Solidified addresses the gap by placing a virtual CISO, or vCISO, inside your team, not a consultant and not a committee. This person is responsible for day-to-day security decisions and oversight.

Why a vCISO works

A protocol’s risk is not static. Risk changes every time a contractor pushes a minor update, a new module is introduced, the team grows, integrations add new assumptions, governance powers shift, or treasury management evolves.

Attackers view the system holistically, while most teams do not. A vCISO provides full-stack visibility, helping teams move quickly without creating unforeseen attack paths.

Continuous security isn’t a marketing checkbox.

Audits fail as standalone solutions because they are periodic, while codebases and environments evolve continuously. Continuous security means regularly checking things like system design, user permissions, code quality, deployment plans, operational practices, key management, threat detection, and being ready for incidents.

No unnecessary meetings or reports. Just structure, accountability, and visibility.

Where Solidified fits

Solidified is designed for teams who do not need hand-holding, do not want fluff, and do not want another PDF.

Teams receive embedded security leadership through a vCISO, full-stack oversight, pragmatic decision-making, attack simulations, architecture design, and incentive-aligned auditing.

This is not “more services”. It is the missing layer between audits and real security.

The mindset shift Web3 needs

Security is not a checkbox, a certificate, or a PDF. It is a discipline. Teams that cultivate security through leadership, ownership, and a continuous process will define the next phase of Web3.

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

Introducing Solidified - raising the bar for Web3 Security

Solidified is our affiliate boutique cybersecurity firm with a mission far bigger than just fixing your code: to build a safer, more resilient industry. Solidified enables security from the ground up. Read our manifesto.

A night to remember in Buenos Aires

We co-hosted a memorable night of privacy talks and cocktails during Devconnect with Bermuda, Safe, Web3Privacy Now, Womxn in Web3 Privacy, Fluidkey and Jordi Baylina (ZisK).

Join our Telegram group to hear about future events!

AI-Powered Security

At Sub0 Symbiosis, Polkadot’s flagship conference, Philip unpacked how AI accelerates audits, vulnerability detection, and attack simulations. Watch here

We talked to the designer of the Digital Euro (CBDC)

The former ECB Director General gave us his perspective on why Euro-stablecoins are struggling - and what Europe must fix. Listen

Join our team!

Senior Blockchain Security Engineer | Job Posting Shared

Senior Zero-Knowledge (ZK) Blockchain Security Auditor (f/m/d) | Job Posting Shared

Phishing is no longer dumb

Phishing has evolved into one of the most convincing, professionalized attack vectors in Web3 and most teams have no idea how close they are to falling for it. Read more

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.

Phishing has evolved far beyond the clumsy “Nigerian prince” emails of the past. Ten years ago, you could spot them instantly with bad grammar, sketchy Gmail addresses, laughable promises of money.

Now? It’s a different game. Today’s phishing attempts are clean, professional, and almost too legit. They’ll reference your actual business, use the tools you already trust, and sometimes even fool seasoned security pros.

If you’re in Web3, this is one of the biggest threats to your team. Let’s break down how attackers work today and what you can do to make their job almost impossible.

What modern phishing looks like

Attackers don’t just “spray and pray” anymore. They research, they plan, and they make things look real. A modern phishing playbook often includes:

• A legit-looking website. The logo, design, and even the domain look right.

• An attractive opportunity. A grant, a partnership, or “urgent business.”

• Respectable-looking accounts. LinkedIn with years of activity, social media that seems active.

• Details about your work. They’ve read your announcements, studied your product, maybe even joined your Discord.

• Professional tone. No typos, no obvious mistakes, everything looks polished.

• Trusted tools. Zoom invites, Slack DMs, Google Docs links you’re used to clicking on.

And here’s a recent favorite:

“Hey, can you quickly approve me to share my screen on Zoom?”

Looks harmless, right? But if you don’t pause to think, the attacker might have really sent a request to remotely manage your computer. That one click can compromise your device.

Your online persona = Their research material

Most phishing works because we overshare. Attackers don’t need spyware if your Twitter, LinkedIn, or Instagram already gives them all the context they need.

• Don’t overshare personal details (location, family, hobbies).

• Keep personal and work accounts separate.

• Remember: every extra detail = one more hook they can use.

The gold standard to avoid getting hooked

Here’s what actually works in practice:

1. Treat unexpected messages as suspicious. Pause before replying or clicking.

2. Don’t click on links in emails. Type out the URL yourself.

3. Use phishing-resistant MFA. Hardware keys beat SMS every time.

4. Open files in a sandbox. PDFs and docs are classic infection vectors.

5. Disable scripts in PDF readers. Still a thing, still dangerous.

6. Use email authentication (DKIM, SPF, DMARC). Stops your domain from being spoofed.

7. Red flags you should never ignore:

   • Time pressure (“do this right now”)

   • Deals too good to be true

   • Requests for unusual tools or permissions

   • Oddly detailed knowledge from a stranger

Bottom line: Zero Trust. Just because something looks professional doesn’t mean it’s safe.

Why this matters for Web3 teams

Phishing is usually just step one. Once an attacker’s in, they go after bigger targets’ private keys, admin accounts, funds. That’s why “spotting bad emails” isn’t enough. Your whole operational setup has to be resilient.

Security isn’t one-and-done. It’s a habit.

Want to go deeper? Join our free Web3 operational security awareness training on December 16.

We’ll cover social engineering tactics, private key essentials, hardware wallet best practices, and practical ways to make your team harder to hack.

It’s designed for everyone on a Web3 team devs, PMs, bizdevs, marketers, community managers, and execs.

Just sign up here and join us online. No cost, no obligations.

Phishing works because it feels normal. The more you slow down, stay skeptical, and practice good habits, the less power attackers have. Add the right team training, and phishing goes from “serious threat” to “minor annoyance.”

Get a quote for your project, schedule a call with our team, follow us on X, and sign up for our newsletter for simplified and curated Web3 security insights.