Cork’s 2025 focus has been building the premier tokenized risk infrastructure, and that means building with uncompromising safety at its core. This requires raising the standard for how DeFi companies approach security, evolving beyond static, one-off audits toward a continuous, holistic approach. To that end, we have partnered with Certora—our Security Partner of Record—to work in partnership with their team of varied security experts across every stage of the development lifecycle, spanning from system design and formal verification to deployment and operational security. This document details Cork’s security approach and outlines the end-to-end approach we’ve taken in building protocol resilience.

‍

Five principles

‍

We kept the philosophy simple and used it to inform every design decision:

‍

1. Full-stack, embedded security approach
   Siloed, sequential audits that are based on the codebase at a moment-in-time are no longer sufficient to secure DeFi. Instead, what is required is a full-stack security approach - one that takes security into consideration from the earliest design conversations through ongoing protocol operations. That is why we’ve embedded Certora across the entire lifecycle building both the protocol and company operations, from design and implementation to testing, deployment, monitoring and OpSec. Seeing Cork as a holistic environment, rather than isolated components, is what allows us to secure it end-to-end.
   ‍
2. Security as a mindset
   The strongest technical stack fails if security consciousness isn’t a part of the team’s DNA. At Cork we are working to ensure that security is present in every decision and action - built into hiring and cultural fit, onboarding, key and access management, engineering and deployments, vendor and infrastructure choices, device and remote-work practices, incident response, public communications, and how we share and store information internally.
   ‍
3. Security as product UX
   We’ve challenged ourselves to explore how new security tools can be used to build a better product experience and improve the user experience when interacting with Cork. We’ve developed human-readable ENS contract names, EIP-7730 clear signing, real-time simulations before confirming a transaction and much more. All of these features are designed to make using Cork a more secure experience for customers.
   ‍
4. Honor Murphy’s Law
   We design our operations with the objective of ensuring that smart contracts and user funds would stay safe even if one or more of our systems were compromised. Every actor (human or machine) gets the minimum permissions required to do the job, for the minimum possible time. We trust nothing, verify, and then only verify again.
   ‍
5. Less is more
   Complexity is an attack surface. Cork has worked for the past six months to simplify its functionality and contract infrastructure to make the codebase smaller, more readable, accessible, and doing that well. Simplicity benefits everyone: team members, auditors, and due diligence professionals better understand the codebase and are significantly less likely to miss critical issues.
   ‍

Here is how these principles have influenced the protocol build and operations: 

Phase 1 – Design
‍

From an early stage of development, Cork engineers & security advisors spent weeks in design sessions on whiteboards full of state diagrams and “what if?” scenarios to develop a simple, robust and secure protocol design.
‍

Three outputs mattered most:
‍

• Security Properties and Invariants
  For each core component, we wrote down what must never happen (e.g. under-collateralized states, stuck funds, broken accounting) and what must always hold under stress. These became our invariants - the backbone for tests and formal specs later.
  
  
• Threat Model
  We mapped concrete abuse cases: oracle failure, rounding error, governance mistakes, denial of service risk and many more. For each, we decided whether to prevent, detect, and limit impact.
  
  
• Threat-Surface Minimization
  Some features that looked attractive on paper did not survive this phase. If they widened the attack surface without changing adoption or core economics, they were pushed out or dropped entirely.

‍

Phase 2 – Build & Test
‍

Once the design and invariants were stable, the protocol team started writing against that spec. The objective was that by the time an auditor opened the repo, they would be reviewing corner cases.
‍

Concretely:
‍

• High-Coverage Tests
  We target 97% test coverage and 100% mutation testing score, with a focus on economically meaningful branches.
  
  
• Fuzzing and Property-Based Tests
  Randomized inputs are driven against assertions wired back to the invariants defined at design time. This surfaced subtle state-transition issues long before external review.
  
  
• Olympix to Catch Bugs Early
  Every code change runs through static analysis to automatically flag vulnerabilities in real time. Mutation testing then checks whether mutated versions of our contracts still pass - if they do, we know a scenario is missing and strengthen our test coverage. Finally, BugPOCer orchestrates Olympix’s proprietary analysis engine (custom compiler, IR, detectors, and symbolic execution) to surface deeper, audit-level findings so we can resolve complex issues internally and make our external audit time as productive as possible.
  
  
• Multi-Agent AI Vulnerability Triage
  For each audit scope, AgentArena by Nethermind spins up competing AI agents against our codebase, routes their findings through an arbiter and human review, and hands us a de-duplicated, severity-ranked vulnerability set with bounties paid out automatically in the background.
  
  

Phase 3 – Verify
‍

With tests green and behavior understood, Cork moved into independent verification.
‍

This stage has two main components:
‍

• Manual Audits by Certora and ChainSecurity
  ChainSecurity is consistently cited in industry rankings as a “top-quality” smart contract auditor, known for deeper reviews and more meaningful issue discovery than most providers. ChainSecurity has secured top-tier DeFi protocols such as Aave, Circle, Morpho, Sky, Pendle and many more.Certora and ChainSecurity each conducted deep, manual reviews of Cork’s smart contracts, going line by line through critical paths, attack surfaces, and economic assumptions. Their teams bring experience from auditing complex DeFi systems and deliver structured findings, remediation guidance, and public reports before any upgrade is cleared to touch institutional capital.
  
  
• Formal Verification with Certora Prover
  Certora is a leading provider of smart-contract assurance, combining formal verification, expert manual audits, and production-grade monitoring into a unified security framework. The company safeguards over $100 billion in onchain assets, securing protocols such as Aave, Lido, and Morpho.Certora encodes Cork’s most critical safety and economic properties as mathematical rules, then uses the Certora Prover, an open-source formal verification tool, to check that these properties hold across all possible contract execution paths. When the Prover flags a violation, we either harden the code or tighten the specification before shipping, turning many potential edge-case exploits into provably unreachable states.
  
  

A release-gate sits on top of this:
‍

• No security issues remain unresolved.
• The agreed invariant set is either proven or bounded with clear assumptions.
• Coverage and fuzzing thresholds are met.
  
  

Phase 4 – Deploy

Deployments are treated as controlled changes.
‍

• Verifiable Pipeline
  Audited Foundry scripts and hardened build images (e.g. Chainguard) ensure that the compiler and toolchain used in deployment match what was used during audits and verification. After deployment, Bytecode onchain is matched against the audited build.
  
  
• ENS-Backed Contract Identities & Metadata
  Each deployed Cork contract is assigned a human-readable Enscribe-powered ENS name and description. This gives integrators and liquidity providers a straightforward way to confirm they are interacting with the intended contract, while also providing risk teams and researchers with a clearer view of our protocol across block explorers. This strengthens security, improves developer ergonomics, and reduces operational risk for participants building on or interacting with Cork.On deployment, each contract registers a pointer to a canonical metadata manifest (IPFS) describing its purpose, source repository, audit references, expected interfaces, deployed commit hash, and security contact. This creates a crawlable, tamper-resistant identity record that external wallets, explorers, and researchers can use to independently confirm they are interacting with the correct Cork contract version.
  
  
• Governance Controls
  All protocol changes are executed through a tiered, multisig-controlled governance system with enforced time delays. We have meaningfully separated out ongoing operations, such as new market creation, from critical operations (eg. role transfers), and have created committed roles that support escalated emergency operations. All governance actions—including queued timelocks and multisig transactions—are fully visible onchain, enabling independent verification by users, integrators, and security researchers.
  ‍

Phase 5 – Operate & Monitor

Once Cork is live, the problem shifts from “is the code sound?” to “how do we respond when reality deviates from our models?”
‍

Cork’s operating stance combines monitoring, controlled access, and a strong OpSec posture:
‍

• Predictive Onchain Threat Monitoring
  Cork contracts have integrated Hypernative monitoring platform, which enables ongoing monitoring and early detection of onchain anomalies in Cork’s platforms. Working with Hypernative specialists in Certora, Cork’s contracts and invariants have been mapped to surface early alerts and enact automated safeguards. SOPs have been defined to balance automated pause-capabilities with the need to keep a live and vibrant market live.
  
  
• Controlled User Approvals
  All too often, users are compromised because dApps request unlimited token approvals and users do not actively monitor or revoke those permissions. Cork’s dApp is designed to minimize both the number and scope of approvals required to interact with the protocol. This reduces user exposure if a contract is compromised or a UI is spoofed, and establishes safer defaults for less sophisticated or infrequent onchain participants.
  
  
• Operational Security
  Cork has worked with Certora to define secure tooling and Standard Operating Procedures around protocol deployment, that incorporates principles of strict least-privilege roles with the latest advancements in hardware wallets and multi-sig operations. This threat surface is constantly evolving and we work with the best so our SOPs evolve with it. 
  ‍

What this means if you build or allocate on top of Cork

For an institutional LP, curator, or integrating protocol, the practical implications are:
‍

• Layered Protection of Capital.
  Cork is built with minimized core logic, high-coverage tests, AI-assisted analysis, multi-firm audits, formal verification, and live monitoring, all as an embedded full-stack security strategy.
  
  
• Predictable Change and Governance.
  The rules for how Cork can change—what can be upgraded, who can act, and under what delay—are explicit and enforceable onchain.
  
  
• Actionable Transparency.
  Audits, formal verification summaries, test repositories, and Enscribe-powered ENS records are published so your own risk teams can verify, not just trust.
  
  

Cork treats security as an always-on discipline. The Cork Security Framework is designed to be continuously updated, tested, and hardened as the protocol evolves. We commit to building and operating Cork with the same mindset as the institutions it aims to serve: explicit assumptions, multiple independent lines of defense, continuous monitoring, and clear operational playbooks.

By working with best-in-class partners like Certora, ChainSecurity, Hypernative, and Olympix Cork commits to a security posture that strengthens over time and aspires to set a new standard for institutional-grade onchain risk infrastructure.

‍