The Hidden Risks of Cosmos SDK: Unmetered Functions

by Eduard Kotysh and Christian Vari

At Oak Security, we’ve noticed a recurring pattern during our audits of Cosmos-based chains: developers often underestimate two important functions — BeginBlock and EndBlock [1]. These functions run before and after processing transactions in each block, and here’s the kicker — they’re not subject to gas metering. This isn’t a mistake; it’s how the Cosmos SDK was designed [2]. However, this has prompted concerns about potential vulnerabilities, such as excessive computation leading to potential denial-of-service (DoS) attacks [3].

The reasoning behind this design choice is pretty straightforward. Since BeginBlock and EndBlock aren’t directly tied to user transactions, initially it didn’t make sense to charge gas fees for their execution. It’s like giving developers a bit of “free” computation time.

But this freedom can be a double-edged sword, and it can open up a Pandora’s box of potential vulnerabilities. The main issue is that without gas limits, poorly optimized or malicious code in BeginBlock and EndBlock can really wreak havoc. It can slow down the network, cause problems for validators, and even halt the entire chain.

To show just how big of a deal this can be, we decided to conduct an experiment. We set up a local test network and introduced some random delays in the consensus process to simulate resource-intensive operations in BeginBlock. The results were pretty eye-opening.

Experimental Validation

To validate these risks, we conducted a controlled experiment on a local network consisting of seven validator nodes. Our test introduced randomized delays in the BeginBlocker function at even block heights starting from block 10, with delays ranging between 5 seconds and 1 minute to simulate resource-intensive operations:

Figure 1: BeginBlock function with randomized delays

This experiment yielded three significant observations:

1. Consensus Timeouts & Multiple Rounds: The introduction of delays triggered multiple additional consensus rounds at affected block heights, significantly slowing overall chain progression and increasing block times.
2. Missed Validator Votes & Slashing Risk: Several validators failed to sign blocks within required timeframes, with some missing voting phases entirely. This exposed validators to potential slashing penalties, with those having slower processing capabilities or weaker network connections facing higher risk.
3. Network Liveness Concerns: When fewer than two-thirds of validators could sign in time, the chain experienced temporary halts. In production environments, this could lead to situations where block finalization becomes impossible, resulting in a completely stalled network.

These experimental results confirm that unoptimized, malicious code, or even intentional data processing in BeginBlock and EndBlock functions can severely impact network performance and stability, even on a test network with minimal traffic.

Prominent Case Study

Cosmos Hub Interchain Security Vulnerability (January 2024)

In early 2024, security researchers identified critical vulnerabilities in the Cosmos Hub's Interchain Security module, specifically within its EndBlock functions [3]. These vulnerabilities, previously found by Oak Security during an audit, while not exploited in production, demonstrated significant risks associated with unmetered execution:

1. AssignConsumerKey Exploitation:

• Location: x/ccv/provider/keeper/relay.go
• Issue: Potential for unbounded growth in the consumerAddrsToPrune list
• Risk: O(n) time complexity in unmetered EndBlock execution

This vulnerability was formally identified in Oak Security's June 2023 audit of Cosmos Interchain Security, where it received a Major severity rating. The audit specifically noted that "malicious actors could craft transactions with multiple AssignConsumerKey messages and spam the provider chain," causing the consumerAddrsToPrune AddressList to grow linearly with the number of messages sent [4]. Since this list is iterated over in the EndBlocker, the execution time would increase proportionally, potentially slowing down or even halting the provider chain.

2. SendRewardsToProvider Vulnerability:

• Location: x/ccv/consumer/keeper/distribution.go
• Attack Vector: Spamming reward addresses with multiple token denominations via IBC
• Consequence: Forced unbounded iterations over reward tokens in EndBlock

This vulnerability was also independently discovered in an audit by Oak Security, where it was marked as Critical. The auditors explained how the SendRewardsToProvider function in the consumer chain's EndBlocker retrieves all coins from the reward address and attempts to send each denomination individually to the provider chain via IBC. Oak Security auditors specifically warned that "since anyone is allowed to send coins to the reward address, an attacker could create and send a large number of coins with different denoms to it, for example using a chain with the token factory module, in order to attack the mentioned unbounded iteration and DOS attack the chain."

This represents a clear example of how unmetered execution in EndBlock functions becomes particularly dangerous when combined with unbounded iterations over attacker-controlled inputs [4].

Get Eduard Kotysh’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Potential Impact Summary:

• Block finalization time could grow linearly with attack intensity
• Significant performance degradation across the network
• Risk of complete chain halts without intervention

This case study reveals that even high-profile projects like Cosmos Hub remain susceptible to unmetered execution vulnerabilities.

Security Recommendations

1. Implement Strict Computation Bounds

• Time Complexity O(1): All BeginBlock/EndBlock operations should have O(1) complexity since these functions execute unconditionally every block (~7-second intervals) without gas constraints. If this is not feasible, benchmarks should be run and upper bounds should be enforced, for example on iteration of stored entities.
• Context Wrapping: Wrap potentially resource-intensive operations, such as the execution of CosmWasm smart contracts, in custom gas-metered contexts tied to governance-controlled params:

• Input Validation: Implement comprehensive validation for all inputs to BeginBlock and EndBlock functions, including strict bounds checking for iteration limits, token denominations, and data structure sizes.

2. Comprehensive Testing Methodologies

• Load Testing: Utilize simulation frameworks (e.g., simapp) to test block execution with elevated validator counts, oversized data structures, and maximum theoretical network loads.
• Chaos Engineering: Simulate 40% validator downtime during EndBlock and Network partitions during BeginBlock.
• Exception Handling Verification: Ensure all calls to external modules within BeginBlock and EndBlock implement proper error handling and recovery mechanisms, particularly for CosmWasm smart contracts and other extensible components.

3. Architectural Safeguards

• Priority Execution Queues: Ensure critical consensus logic can't be blocked by lower-priority operations
• Automated Circuit Breakers: Implement on-chain parameters that allow for the automatic disabling of non-critical BeginBlock and EndBlock logic during performance degradation or attack scenarios
• Governance-Controlled Parameters: Require explicit governance proposals for modifications to BeginBlock and EndBlock hooks, preventing incremental risk accumulation through seemingly minor additions

4. Operational Monitoring

• Performance Metrics: Establish dedicated monitoring for key metrics:
  - BeginBlock_duration_ms
  - EndBlock_duration_ms
  - Iteration counts within unbounded loops
  - Memory allocation patterns during block execution
• True Anomaly Detection: Implement alerts for significant deviations in these metrics across validator sets and use historical baseline comparison to differentiate targeted attacks vs natural load spikes.

The Cosmos SDK provides developers with exceptional flexibility in certain areas, but this flexibility could act as a double-edged sword without rigorous security practices. These unmetered functions represent a unique attack surface where even minor implementation errors can cascade into chain-halting threats. Security auditors must rigorously review these functions with specialized test methodologies, while developers should implement strict computational bounds and monitoring systems as defensive measures.

Our team at Oak Security brings a deep understanding of intricate design trade-offs when it comes to Cosmos security models and can help you cover all aspects of architectural review, from early planning, secure design, economic consulting, secure development processes, and in-depth protocol reviews.

Check out our audit reports or contact us via email and social media channels on X or LinkedIn.

REFERENCES

1. Cosmos Network Documentation, BeginBlock and EndBlock. https://docs.cosmos.network/v0.45/building-modules/beginblock-endblock.html. Accessed March 28, 2025.
2. Fault Tolerant Systems, Cosmos Security Part 1: Unmetered Functions. https://www.faulttolerant.xyz/2024-01-16-cosmos-security-1/. Published January 16, 2024. Accessed March 28, 2025.
3. Gate.io, Cosmos Ecosystem Security Guide: Analyzing Security Challenges in Different Components. https://www.gate.io/learn/articles/cosmos-ecosystem-security-guide-analyzing-security-challenges-in-different-components/1628. Accessed March 28, 2025.
4. Oak Security, Audit Report — Cosmos Interchain Security v1.0. https://github.com/oak-security/audit-reports/blob/main/Cosmos/2023-06-23%20Audit%20Report%20-%20Cosmos%20Interchain%20Security%20v1.0.pdf. Published June 23, 2023. Accessed March 28, 2025.