Vulnerabilities In Permissioned Capital Market Smart Contract Protocols

Since the creation of Uniswap in November 2018, Decentralized Finance (DeFi) protocols have been the dominant form of smart contracts on Ethereum and in other blockchain ecosystems. More recently, Traditional Finance (TradFi) institutions have begun to embrace smart contract technology. First through tokenization of Real World Assets (RWA) then through the development of increasingly complex Permissioned Capital Market (PCM) protocols, enabling on-chain trading and settlement of tokenized RWAs within a regulated, compliant environment.

While openly accessible publishing of audit reports and smart contract security vulnerability deep dives is common for DeFi protocols, TradFi audit reports are almost never openly published at the request of the institutional clients who value discretion. This article will showcase different categories of TradFi vulnerabilities uncovered during Cyfrin private audits while respecting and maintaining the confidentiality of our TradFi clients.

‍

TradFi PCM vs DeFi

There are three major differences between TradFi and DeFi protocols: Permission To Participate, Capital Requirements, and Regulatory Compliance.

‍

Permission to participate

DeFi protocols are commonly permissionless. Meaning anyone can create a wallet, fund an address, and freely interact with it. In “pure” DeFi protocols, once tokens or other resources are acquired, a user has “sovereignty” over those assets such that they can’t be frozen or seized by protocol admins; they are free to transact without dependency upon, or liability to, a trusted third-party “administrator.”

While maximizing individual freedom and liberty, this also makes DeFi the most hostile environment in which to deploy code. One consequence of allowing anyone to interact with DeFi protocols has been the many spectacular multi-million dollar hacks executed by completely permissionless & anonymous entities. 

Around the height of the prior bull market in 2022, DeFi’s highest TVL reached $137 billion but a staggering $3.7 billion (2.7%) was stolen by hackers that same year!

In contrast to DeFi’s open and permissionless nature, TradFi PCM protocols allow only known, pre-approved participants to interact with the protocol who are typically subject to KYC/AML and can pass “qualified investor” checks. 

While this may limit participation, it also eliminates an entire class of attack vectors found in permissionless DeFi. When PCMs are correctly configured, permissionless attackers are unable to call any state-changing functions and therefore have no entry-point into the protocol.

A secondary aspect of PCM protocols is that trusted administrators typically have the power to freeze and seize tokenized RWAs from users. Users who have acquired RWAs don’t have full sovereignty over those assets and are dependent upon the continued permission of protocol admins for their ownership of those assets. 

While this further restricts the freedom and ownership rights of individual users, it also greatly enhances the potential security response in the event of a hack. Fast-responding admins can seize a hacker’s stolen assets and return them to their rightful owners.

This exact scenario recently played out in the “pseudo DeFi” world of alt-L1 chains without a truly distributed validator set and L2 chains using centralized sequencers. Protocol teams censored hacker transactions, froze their funds [1, 2], and even used extraordinary powers to seize hacker assets. 

The reality today is that while some pure DeFi protocols do exist, the majority of DeFi protocols, including major “decentralized” blockchains, are actually pseudo DeFi. They use decentralization for marketing while in reality are highly centralized, with effective power to restrict user freedom to transact and freeze/seize assets.

In this regard there’s little difference between PCM and pseudo DeFi protocols, except that PCM protocols:

• Are more upfront about the powers of protocol teams and administrators, while pseudo DeFi protocols quietly maintain similar powers which they are quick to use when responding to emergency situations.
  ‍
• Have a reduced attack surface. Because, when correctly configured to prevent permissionless entities from calling state-changing functions, PCMs are immune to the same type of spectacular permissionless/anonymous hacks that cripple both true DeFi and pseudo DeFi protocols.

‍

Capital requirements

Many DeFi protocols do not impose capital requirements on users. Or, if they do, they are relatively small such that almost any human in the developed world can meet them.

In contrast, PCM protocols often impose high capital requirements and require transaction minimums in the many thousands or even millions of dollars.

While the philosophical debate over the freedom to transact and sovereignty over assets is interesting, the more practical reality of capital requirements means that the vast majority of humanity, even in the developed world, is financially unable to participate.

‍

Regulatory compliance

DeFi is effectively the wild west. New innovations compete side-by-side with meme coins, ponzi schemes and rug-pulls for user capital and attention. TradFi PCM protocols, on the other hand, operate within a highly regulated and compliant environment, even when operating on the same blockchains. 

To satisfy regulatory and business compliance requirements, PCM protocols implement on-chain and off-chain infrastructure code to track multiple data points and enforce compliance rules on investors and products.

When users transact with DeFi smart contracts they are interacting with only that code, often with no clear legal entity or government-approved regulatory framework to oversee the interaction. 

In contrast, when users interact with PCM smart contracts, they are interacting and transacting with known, regulated entities. Users have full legal recourse including the ability to appeal to government regulatory bodies that license and oversee regulated financial entities.

‍

TradFi PCM vulnerabilities

Over multiple Cyfrin private audits for TradFi institutional partners, we have uncovered the following range of PCM vulnerability classes:

‍

Tracking data corruption subverts compliance rules

To enforce regulatory and business compliance rules on-chain, PCM protocols:

• Contain many tracking “hooks,” called after actions, that track data points related to users and products.
  ‍
• Contain compliance hooks, called before and after actions, that retrieve data and perform checks against it.
  ‍
• Will often revert a transaction or may impose other restrictions such as amount limits if a check fails. 

‍

A consistent class of high-impact vulnerabilities we have identified result in this tracking data becoming corrupted due to:

• Mismatched encoding/decoding of tracking data parameters.
  ‍
• Missing tracking hooks resulting in particular data points not being updated during transactions where they should be updated.
  ‍
• Stacked tracking hooks resulting in multiple updates per transaction to the same data points when only one update should occur.
  ‍
• Missing compliance hooks resulting in particular compliance rules not being enforced during parts of some transactions where they should be enforced.
  ‍
• Logic bugs inside compliance hooks that tend to be more complicated than tracking hooks.
  ‍
• Incorrect parameters passed to tracking hooks that result in corruption of data points.
  ‍
• Edge-case states where it becomes impossible to disable or remove hooks, even though the admin had a legitimate reason to do so.
  ‍
• Edge-case states where a compliance hook appeared to be working, but because the tracking hook it depended on was disabled, the hook silently malfunctioned.

‍

The most common impacts of tracking data corruption bugs are:

• Denial Of Service: Core protocol functions panic revert due to underflow/overflow and the protocol becomes mostly unusable. While severe and very disruptive, it does make the problem known to protocol admins who can correct the error by fixing the corrupted data points, thereby restoring the protocol to a correctly functioning state.
  ‍
• Subtle Misbehavior: Regulatory and compliance rules appear to work as designed but are actually subtly malfunctioning because the compliance hooks are getting incorrect data as inputs. This kind of issue is potentially more severe since there are no obvious errors. Protocol admins believe everything is working correctly while regulatory and business compliance violations are happening.

‍

Admin actions result in inconsistent state

Larger more complicated PCM protocols also have a range of admin actions designed to be used in scenarios to enforce regulatory or business compliance rules. 

Our audits have found vulnerabilities and bugs are frequently found in complex admin function code that is not commonly used and that must operate over a large range of potential user and protocol states. Examples include:

• Force redeeming user assets in a specific state corrupted the value of a variable which broke a key invariant, causing future settlements to panic revert from underflow.
  ‍
• Force redeeming in a specific state corrupted a tracking data point, causing its associated compliance hooks to silently malfunction.
  ‍
• Force cancelling an order in a specific state corrupted a tracking data point causing future compliance checks to subtly malfunction.
  ‍
• Revoking user credentials prevented users from receiving new credentials in the future.
  ‍
• Updating the credential schema prevented future revocation of previously created user credentials under the old schema.

‍

Privilege misconfiguration and escalation

PCM protocols must be carefully configured with fine-grained access controls and specific levels of privileged access for all users. 

We have found a variety of bugs within the access control logic such as:

• Missing access controls where publicly callable state-changing functions were added without any access control when access should have been limited to protocol admins. These vulnerabilities can be extremely damaging when they occur on functions used to change the address of important contracts.
  ‍
• Missing overrides such that some inherited, publicly-callable state-changing functions from standard ERC-20/ERC-721/ERC-4626 contracts were still accessible without restriction.
  ‍
• Privilege escalation where a user that received some level of access in the protocol can exploit a bug in the access control system to gain additional, unauthorized, privileges.
  ‍
• Fund managers can perform privileged actions for their own funds and other funds they have no authorization to manage.
  ‍
• Tokens that should only be held by KYC’d addresses can be transferred by normal users to non-KYC’d addresses, not registered to any user.
  ‍
• Users can initiate actions such as buy or sell and direct the output tokens to non-KYC’d addresses in breach of compliance rules.
  ‍
• When removing tracking hooks, permissioned roles granted to them were not revoked.
  ‍
• Missing admin functions to quickly and easily respond in the event of a private key compromise.

‍

Front-running

While front-running attacks and economic exploits are common in DeFi, the restricted and permissioned nature of TradFi PCM protocols reduces the impact of such attack vectors. 

In our TradFi PCM audits to date we have found one way that front-running could be abused. It allowed users to evade admin actions (such as a forced redemption to revert) by front-running and transferring tokens to another address they control.

‍

Input validation, rounding, slippage, and precision loss

Similar to DeFi, TradFi protocols involve financial calculations and must be careful about input validation, rounding direction, slippage and precision loss errors. Round up fees against users, specifying slippage parameters, being aware of precision scaling, rounding down to zero errors–we have found all the same DeFi bugs in our TradFi audits including:

• Missing or inadequate input validation allowing transactions on behalf of others.
  ‍
• Precision loss due to division before multiplication and rounding down to zero that result in the loss of funds.
  ‍
• Missing slippage parameters when swap/liquidation output is based on dynamic exchange rates returned by Net Asset Value (NAV) providers can result in less output tokens than expected.
  ‍
• Mismatched or missing precision scaling. We found at least three critical vulnerabilities in TradFi vault implementations where the integration of NAV exchange rates resulted in:
  ‍
  
  • Vault shares being returned using an incorrectly smaller decimal precision, leading to significant financial losses for vault users.
    ‍
  • Redemptions returning output tokens using an incorrectly larger decimal precision, paying out much larger amounts to users and leading to a significant financial loss for the protocol.
    ‍
  • Checks for available liquidity reverting due to comparing against values using mismatched decimal precision. This incorrectly prevented user redemptions even though sufficient liquidity was available.

‍

Cross-chain PCM vulnerabilities

Advanced PCM protocols operate cross-chain, allowing users to bridge both credentials and tokenized RWAs to other blockchains. When auditing cross-chain PCM functionality some vulnerabilities we have found include:

• Insufficient source validation on the destination chain allowed an attacker to craft malicious messages, containing valid data, triggering minting of tokens on the destination chain.
  ‍
• Edge-cases where transactions could be executed more than once on the destination chain.
  ‍
• Edge-cases that can break cross-chain user credential synchronization.
  ‍
• Inability to re-try failed delivery on the destination chain that results in tokens on the source chain being locked.
  ‍
• Incorrect handling of block re-orgs that result in users receiving tokens on the destination chain when they never surrender their tokens on the source chain due to a block re-org on the source chain.
  ‍
• Identical cross-chain addresses on external chains can be associated with multiple investors on the source chain.
  ‍
• Incorrect address validation for alt-L1s using different address formats breaks the bridging to those chains.

‍

Missing or under constrained vulnerabilities

In Rust-based ZK and Solana audits for PCM protocols, we have identified a range of missing or under-constrained vulnerabilities such as:

• Precision manipulation due to missing mint checks, allowing an operator to mint an arbitrarily large amount of shares in a vault, and redeem them for real assets. Thus, draining the vault and diluting all other users.
  ‍
• Bypassing a range of compliance checks due to under-constrained zk circuits.

‍

TradFi PCM gas optimization

TradFi smart contract protocols can be especially “heavy” due to the large amount of defensive armor and tracking/compliance checks required, in addition to the normal code. 

For EVM-based protocols, the same gas optimization techniques [1, 2] apply including:

• Cache identical storage reads: During each transaction only read the same storage slot once.
  ‍
• Cache common variables and pass them to child functions instead of re-reading them from storage in child functions.
  ‍
• Cache storage writes: Instead of writing to the same storage slot multiple times, update a local variable then write to storage once at the end of the transaction.
  ‍
• Avoid iterating over every list element:  This is expensive and, in a worst-case scenario, can result in an out-of-gas, denial of service.
  ‍
• Use named return variables when it will optimize away a local variable declaration, especially for memory return variables.
  ‍
• Prefer calldata to memory for read-only function inputs.
  ‍
• Fail fast: Revert as quickly as possible with minimum amount of storage reads or other code execution not related to the revert.
  ‍
• Storage variables only set once in the constructor for non-upgradeable contracts should be declared immutable.
  ‍
• Don’t initialize to default values.
  ‍
• Enable the optimizer.
  ‍
• Don’t copy entire structs from storage to memory when only a few fields are needed.
  ‍
• Efficiently pack storage slots, especially where variables are read or written together.

‍

Conclusion

Despite PCM protocols generally not allowing audit reports to become public, there is a lot researchers and security professionals can learn from them.

Novel use cases and unique vulnerabilities introduced by the compliance and regulatory requirements of permissioned TradFi protocols augment the overlap in bugs found between TradFi and DeFi protocols. 

Understanding the multitude of potential attack surfaces is essential to better security and a stronger blockchain industry. By generalizing these findings, we hope to extend industry knowledge enabling researchers to better hone their craft. 

If you are building an institutional RWA or PCA (TradFi) application or DeFi protocol seeking to strengthen your security, Cyfrin Audits can help, contact us today! 

‍