Skip to main content


On this page we explain risks related to Cargo protocol, both from the systems (contract) perspective and from exogenous elements external to pure tech considerations. We also try to rank the risks by their perceived severity, from 1 being low impact and 5 being a show stopper. Naturally, there are various risks that would be identical across the entire DeFi space, such as smart contract risk, hack risk, not to mention standard operational concerns. In due time we will classify those as well. However, the below section is focused on the risk that are characteristic for the Cargo protocol due to its operating model, particular segment of DeFi it operates in and so on.

Cargo Protocol specific risks

RiskDescriptionMitigationSeverity score
Downstream change risk 1 - DEXCurrent version of the protocol is being built on top of services that create and maintain liquidity management strategies on Uniswap V3 and its equivalents (incoming Sushi Trident as an example). Once Uni V3 is replaced by Uni V4 and if it’s a radically different design, rebalancers might gradually lose users and TVL and so will Cargo. That being said, such changes would likely not be happening in a rapid fashion and rebalancers would have the time to adjust their utility offering and so would Cargo. Further to this, similar to V2, which is still functional and is being actively used, V3 also likely will follow the same pattern.Maintain the service as is for Uniswap V3-related rebalancers and their equivalents on other platforms/blockchains. Where possible, align along with what the LP Management would be moving into in the event Uniswap V4 is substantially different in its design vs V3.3
Downstream change risk 2 - rebalancersIf a rebalancer / LP manager radically changes the components Cargo protocol interfaces with (e.g. deposit, withdraw or reward token supply functions), there may be a disruption in the services Aggregator is providing to its users for that specific rebalancer. That would last until the unexpected change is assessed and remediation code update is rolled out. Mitigation would be dependent on the reason of this rapid downstream change. →For example, if the rebalancer updated their pool implementation following a hack, then Cargo should stop its users from depositing on the exploited integration. If the rebalancer in question updated their pool implementation and is deploying new pools, then there is nothing wrong with old integration and there is no reason for stopping it (similar to Uniswap V2 vs V3 transition). In this event an assessment would need to be made if the new pools require an additional update to Cargo infrastructure as well.4
Commercial model riskAt the moment, primary revenue model for the protocol in design stages is a fee-based approach, charging a fixed or variable amount on the tokens managed via Cargo. When users go directly to the rebalancers, foregoing Cargo protocol wrapper and portfolio management services, Cargo revenue stream would be reduced. That’s why, while fee-based approach is, by design, one of initial revenue ideas, there are multiple ancillary products in the roadmap that should help to mitigate this risk.As mentioned in the description, there are several additional products that could be stapled on top of the aggregator services and replace the initial revenue-making model. See the roadmap for the latest stack of work view. Those are going to be prioritised as soon as initial integrations with existing rebalancers are complete.3

Other protocols’ risk frameworks / security assessments

Gearbox: and

Aave: - a god-tier risk framework example

Jones DAO:



Maker DAO:

Euler Finance:


Universe Finance:


Nexus Mutual: and

DeFi risk classification articles