Intro: Understanding the oxygen protocol

When Kudelski Security approaches a security assessment of a FinTech company such as Oxygen, we always aim to provide a full suite of coverage to ensure that the architecture, application, and operation of the environment is sound and free from known vulnerabilities or DeFI style attacks.

In the case of a DeFI ecosystem, there are always moving parts of dependencies, relationships, and workflows that may be dynamic. You may not always know the workflow, even if you know the components. In this manner, it is important to always understand the picture of the entire system, review the flow, understand the purpose and functionality and then view the system from the point of view as an attacker.

As a philosophy, a protocol such as Oxygen – in addition to providing the financial functions that it has been designed to provide – must protect its components from impact/liquidation even if one of the dependent components introduces a failure or economic scenario that is not intended.

While not every security risk can be uncovered by a single review, the artifacts that are created can be used as input for the organization to build security risk and operational controls into its system to better handle unintended system interactions. Whether it be economic or system level attacks, the security of the system takes review, continuous testing, analysis from experts in the form of pen testing or bug bounty, and review by legal and economic experts.

Within this lens, we are undertaking a series of assessments related to the Oxygen Protocol and supporting architecture and openly discussing the methodology to drive understanding further into the industry. We will conduct a series of reviews and audits of the Oxygen Protocol functionality and interfaces, as well as collaborating with Oxygen going forward to assess future enhancements, changes, or additions to Oxygen’s protocols. 

As they state, beginning with prime brokerage, Oxygen intends to replicate a growing range of products offered by investment banks, helping to build finance without Wall Street. As a DeFi ecosystem, Oxygen intends to enable delivery of these services to individuals and institutions alike, democratizing access to sophisticated investment, risk management and liquidity solutions.

As a security provider, understanding the outcome desired by Oxygen drives our review criteria and also identifies which sorts of fraud, risk, and security controls that must be built into this sort of system. Traditional entities are built upon years of security learnings and audits, and any project intending to replicate this functionality should also deliver equivalent functional controls.

These controls deliver protections such as:

  • Protection of the environment in case of denial of service attack
  • Protection of the funds in case of economic attack
  • Protection of the users in case of scenarios of monetary abuse, account abuse, or collusion
  • Protection of the infrastructure from compromise by malicious entities
  • Protection of the all components from accidental impact by dependent projects or internal resources

Security projects utilizing a STRIDE methodology along with appropriate control points and attack trees generally can understand and prioritize their risk surface, similar to how Oxygen is progressing.

As a protocol, Oxygen is built on the growing and liquid Serum ecosystem which leverages an on-chain orderbook to match borrowers and lenders to provide fair rates. And it is made possible by the massive throughput and ultra-low costs of the scalable Solana blockchain. Kudelski Security has previously performed assessments for Solana and has compiled a repository of knowledge which will be leveraged to better understand and review the Oxygen system.

In a follow-up article, we will discuss our process and outcomes from the review of the Oxygen ecosystem. Much can be learned from the attention on the Contracts Mechanism, Finance Logic, Yields, Borrowing, Lending and Leverage mechanism security controls and constraints, as well as other related funds safety considerations – such as whale attacks and collusion. 

We will also discuss how “formal verification analyses” can confirm that formulas, cryptography and mathematics, etc. in the software faithfully implement the specified intent of the protocol.

Our final update will include the methodology of testing, which includes a discussion of the benefits of architecture review, dynamic testing of key financial risk scenarios such as edge situations, liquidity events, and more versus scripted testing or a pure static analysis.

More to come…

Leave a Reply