Security research firm Zellic has completed a comprehensive, 33 week audit of the Radix code base with a focus on asset safety, architectural design security, and liveness.  Their findings were overwhelmingly positive, with only six issues discovered and none of high or critical impact.  All issues other than one “informational” notice were promptly remediated before the conclusion of the audit.

The Zellic team had initial skepticism of the novel Radix security architecture, which dispenses with the common authorization stems from the caller pattern in favor of a badge-based, unified security model, but the auditors quickly understood the flexibility and robustness of the design; they wound up complimenting its simplicity and straightforwardness, noting that it completely avoids many opportunities for subtle bugs seen in other networks.

Audit Methodology

Zellic has extensive experience reviewing L1s and L2s, EVM-based as well as Aptos, Sui, Solana, Berachain, LayerZero,, and Cosmos.  Their audit process is structured to look for:

• Coding mistakes - a common cause of vulnerabilities, code mistakes are errors which are not a failing of the overall design or architecture, but garden variety bugs that can have disastrous consequences.
• Architecture risks - hazards which originate from fundamental attributes and assumptions of the system.
• Arithmetic issues - problems arising from mathematical operations, such as overflows and underflows, incorrect rounding, loss of precision, and the like.
• Implementation risks - risks associated with translating the overall system design into the practical reality of layered, interconnected implementations in code.
• Availability issues - issues which can cause temporary or permanent halts in liveness, stemming from things like unhandled panics, unbounded computation, or ways to introduce consensus failures like non-determinism.

Findings

Radix performed extremely well across the board, with the audit team repeatedly coming away impressed with the defense-in-depth security philosophy and strong ownership guarantees.  Time and time again, the auditors would announce their expectation that they would be able to cause an unpermitted action by injecting a scenario which bypassed an expected authorization check at a higher level, only to discover that it was impossible as no layer trusts the layer above it.

The architecture performed similarly well against attempts to induce liveness issues through inventive ways at causing panics; again the layered design successfully constrained all user code-level issues and all system calls were rigorously tested and found that all panics were safely and correctly handled.

Most of the issues discovered were related to the fee costing of certain operations, effectively allowing a knowledgeable attacker to cause the network to spend more time in validation than their transaction’s XRD cost would normally allow.  Such issues were easily remediated with an updated fee table.

An issue related to subgroup membership checks in BLS signature aggregation in Scrypto was also discovered; where the subgroup check of the first signature was ignored. The correct checks were applied during aggregate signature verification, and no practical attack could be demonstrated.  However, it was certainly incorrect behavior and was likewise promptly fixed.

Praise for the Resource and Badge Systems

Zellic’s auditors were quick to identify Radix’s native resource model as a standout feature, noting how it allowed the execution engine to handle maintaining invariants and removed the possibility of numerous commonly-seen bugs related to token handling on other networks, both at the system and smart contract levels.

They were impressed with how elegantly this flowed into the badge-based security model, commenting “It is a very clean and simple system, and it is incredibly difficult to introduce access-control issues through user error.”  They go on to praise the access control model, singling out the native Account component as an example:

Another key point is that access control in Radix is the default. A good example of this is the native accounts blueprint. In Radix, every account is a component created from the native accounts blueprint, and so the actual logic within each account is restricted to what the native accounts blueprint implements. This ensures that any security measures (such as not allowing users access to accounts that they are not authorized to access) are implemented at a blockchain level. This makes it absolutely impossible for any implementation level issues to arise out of user error.

In contrast, to implement smart accounts on Ethereum, not only do user-defined smart contracts need to be used (see ERC-4337 for example), but off-chain entities must also be used to submit transactions on behalf of these smart accounts. Additionally, since smart contracts do not automatically contain access-control logic, all access-control must be implemented manually by the developers of the smart account system.

Praise for the Security and Ownership Systems

The easy-to-reason-about model of single ownership and strong security guarantees repeatedly garnered compliments throughout the audit process, with the auditors able to do away with entire classes of common bugs due to them being impossible to achieve within the Radix architecture.  

In the audit report they use an example of a flash loan being difficult to safely code and validate on other networks, “but in Radix it is a straightforward exchange of resources, with clear intent and security guaranteed by the ownership rules themselves.”  They go on to say “This pattern can be found throughout Radix at every level of implementation. Even core features like resource management rely on these ownership rules rather than complex invariants being checked…simple rules create strong security.”

Closing Thoughts

This was an extremely comprehensive review process, and Zellic’s auditors were impressively quick to get their heads around Radix’s unique architecture and design philosophy. The Zellic auditors provided consistent communication throughout the audit process, quickly responding to all questions and daily updates. All findings were reported as soon as they were discovered, allowing for quick fixes and resolutions. Both teams thoroughly enjoyed the process, and the architectural decisions made for the Babylon release were again put under the microscope and subjected to intense discussion and rigorous testing.

Just as with the earlier audit conducted by Hacken, the best part was watching the auditors’ professional skepticism gradually switch over to admiration for the design and implementation.

If you would like to read the full Zellic audit, you can do so here [link]

‍