Composability in Ethereum: Creating New Possibilities by Building on Existing Work

Disclaimer: This article is for informational and educational purposes only and simplifies underlying technical concepts for clarity. It is not financial, investment, or security advice.

One of Ethereum's most powerful features is composability, the ability to combine existing smart contracts to create new applications and services.

In the previous modules, we explored how individual smart contracts can execute predefined rules without relying on a traditional intermediary. Composability takes this a step further. When thousands of smart contracts operate on the same open blockchain, each contract becomes a building block that other developers can use.

A lending service can use a price service to value collateral. A savings application can combine several lending services to find attractive interest rates. Each application builds on existing functionality rather than recreating everything from scratch.

This creates a fundamentally different way of developing products. Instead of negotiating partnerships and integrating separate systems, developers can often connect directly to existing smart contracts.

Composability is one of the key reasons Ethereum's decentralized finance (DeFi) ecosystem has grown so rapidly. It also introduces new risks because an application may depend on contracts that its developers neither own nor control.

1. What Does Composability Mean?

The LEGO analogy

Imagine a collection of LEGO bricks. Each brick has connection points that allow it to fit with other compatible bricks, regardless of which set it came from.

You do not need permission from the person who designed a brick to use it in your model. You can combine existing bricks to create something new, and someone else can then use your creation as part of an even larger structure.

Smart contracts on Ethereum work in a similar way.

Each smart contract exposes functions that other contracts can call, subject to the contract's interface and access restrictions. Developers can combine these functions to build new applications. Once deployed, those applications can themselves become building blocks for other developers.

This is why DeFi applications are often described as "money LEGO." Lending, trading, token issuance and yield generation are separate capabilities that can be assembled into more sophisticated financial products.

The shared app store analogy

Imagine if every application on your phone could directly use the features of other applications without requiring their developers to negotiate partnerships.

A fitness application could use a payment application to collect class fees, which could in turn use a currency conversion service to show those fees in each customer's local currency.

On the traditional internet, these integrations usually require companies to build and maintain APIs, negotiate commercial agreements or obtain access to another company's systems.

Ethereum offers a different model. Smart contracts deployed on the same blockchain operate within a shared execution environment. Their exposed functions can be accessed by compatible applications without requiring a commercial partnership between their developers.

Contracts may still restrict who can use them (see Section 3), and applications must be technically compatible. Even so, the underlying infrastructure is open to developers by default.

Three related concepts

These concepts reinforce one another. Shared standards make integration easier, while permissionless access allows developers to experiment without waiting for individual partnerships.

2. Why Does Ethereum Make Composability Possible?

Composability is not a separate feature added on top of Ethereum. It emerges from several characteristics of the network.

2.1 Public smart contracts at known addresses

A deployed smart contract has an address on Ethereum. Users and other contracts can interact with it through its exposed functions.

For example, a developer creating a lending application does not necessarily need to build a new token exchange. The application can call an existing exchange contract to execute supported swaps.

The developer needs to understand the contract's interface and satisfy its requirements, but does not need permission from the exchange's original developer merely to integrate with its public functionality.

2.2 One shared state

Ethereum maintains a shared state containing account balances and smart contract storage. Contracts can interact within the same execution environment and access information exposed by other contracts through their interfaces.

For example, a lending protocol may need to determine the market value of collateral before allowing a user to borrow.

It can call an appropriate price-feed contract to retrieve a price, then use that information in its own calculations.

The lending protocol does not need to maintain a separate price service if a suitable one already exists.

This is different from two traditional companies operating independent databases. Their systems generally need explicit integrations to exchange information.

2.3 Shared standards

Ethereum standards help different applications understand and interact with common types of assets.

Consider ERC-20, the standard interface for fungible tokens.

A developer can build an application that supports ERC-20 tokens through standard functions for transferring tokens, checking balances and managing allowances. The application can then work with many compatible tokens without requiring a completely different integration for each one.

For example, USDC and DAI can both be used by compatible applications because they implement the ERC-20 interface.

The standard does not guarantee that every token is safe or suitable for every application. Developers may still need token-specific checks. However, standards substantially reduce the work required to support different assets.

2.4 All-or-nothing transactions

Ethereum transactions can call multiple smart contracts in sequence. If an operation fails and the failure causes the transaction to revert, the transaction's earlier on-chain state changes are undone.

For example, a transaction might borrow assets through a flash loan, trade those assets on a decentralized exchange and repay the loan.

If the required repayment cannot be completed, the transaction can revert rather than leaving the borrower with the loan proceeds.

This property enables atomic composability, where multiple operations are executed as one indivisible transaction.

Together, public contract interfaces, shared state, common standards and atomic execution make Ethereum particularly suitable for composable applications.

3. Smart Contracts Can Restrict Direct Access

Although Ethereum is permissionless, not every smart contract is open to interaction by every address. Developers can build access controls into a contract to determine which wallets or other contracts are allowed to execute particular functions.

For example, a lending protocol might allow only approved addresses to borrow assets. It can enforce this restriction by checking the caller's address before executing the borrowing function. If an unapproved address attempts to borrow, the transaction reverts. Other common mechanisms include restricting certain functions to the contract owner, requiring specific roles, or maintaining an allowlist of eligible addresses.

These restrictions also affect composability. A developer may be able to call a protocol's functions directly from another smart contract, but the call will succeed only if it satisfies the protocol's access rules. An application cannot bypass an on-chain restriction simply by interacting with the contract through a different interface. However, a restriction imposed only by a website or application interface may be bypassed by calling the underlying contract directly, if the contract itself does not enforce that restriction.

A protocol with unrestricted functions may be integrated by a wide range of applications, while a permissioned protocol may limit integration to approved addresses. Composability therefore does not necessarily mean unrestricted access; it means that contracts can interact, subject to the rules and permissions enforced by each contract.

4. A Worked Example: How Multiple Services Fit Together

To understand how composability works in practice, consider a savings application that helps users put their digital assets to work.

The application could combine several existing services. In the diagram below, each arrow points from a service to a building block it relies on. The savings application uses two lending services and a trading service; both lending services rely on a price service; and every service holds and moves tokens.

Building block 1: Tokens

Tokens such as USDC and WETH (wrapped ETH) represent the assets users hold and transfer.

ERC-20 provides a common interface for fungible tokens, allowing compatible applications to interact with them.

Building block 2: Price services

A price service such as Chainlink can provide market information to smart contracts.

A lending protocol can use this information to value collateral, assess borrowing limits and determine whether a position is at risk of liquidation.

Building block 3: Trading services

A decentralized exchange such as Uniswap allows users to exchange one token for another.

It uses token contracts and liquidity pools to facilitate supported swaps.

Building block 4: Lending services

A lending protocol such as Aave allows users to supply assets, earn interest and borrow against eligible collateral.

It can use price information to value collateral and apply its borrowing and liquidation rules.

Building block 5: Savings applications

A savings application can combine several lending services and compare their available rates. It may move or allocate deposits according to its strategy, using a trading service to swap between assets where needed.

The developer building the savings application does not need to create a new token, price feed, exchange or lending engine. The team can focus on the layer that makes its product unique, such as comparing rates, managing deposits or simplifying the user experience.

This reduces development time and cost.

5. Real-World Examples of Composability

Example 1: Borrow on Aave and swap on Uniswap

Suppose an investor holds ETH and wants to acquire another token without selling their ETH outright.

A composable application could coordinate the following operations:

1. The investor deposits eligible ETH collateral into Aave.
2. Aave allows the investor to borrow USDC against the collateral, subject to its risk parameters.
3. The application uses Uniswap to swap the borrowed USDC for another token.
4. The investor can use the acquired token in another compatible application.

Aave provides the lending functionality, while Uniswap provides the swapping functionality.

The developer can combine these capabilities without rebuilding either protocol.

The investor still has a debt obligation, including applicable interest, and may face liquidation if the collateral value falls sufficiently.

With the right setup, these on-chain actions can be bundled into one Ethereum transaction. If a required step fails and the failure propagates, the entire transaction reverts, so the earlier state changes are rolled back too.

Example 2: Flash loans and arbitrage

Flash loans demonstrate how composability can enable operations that would otherwise require substantial upfront capital.

Suppose a trader identifies a price difference for the same token on two exchanges.

The trader could execute the following sequence within one transaction:

1. Borrow 1 million USDC through a flash loan.
2. Buy a token on Exchange A, where it is cheaper.
3. Sell the token on Exchange B, where it is more expensive.
4. Repay the flash loan plus its fee.
5. Retain any remaining profit after gas and trading costs.

The flash-loan contract, exchange contracts and repayment logic work together to execute the strategy.

If the transaction cannot repay the required amount, the transaction reverts, undoing its on-chain state changes.

Flash loans can make certain trading opportunities accessible without the trader supplying the entire principal upfront. However, profitability is not guaranteed, and the same mechanisms can be exploited in attacks when protocols have weak security or pricing assumptions.

Example 3: Using a stablecoin across multiple protocols

Consider DAI, the stablecoin associated with MakerDAO, now known as Sky. Sky has since introduced a newer stablecoin, USDS, but DAI remains in circulation and is widely supported.

A user can obtain DAI through a supported mechanism and then supply it to a lending protocol such as Aave, provided the relevant market supports DAI.

The stablecoin system and the lending protocol perform different functions. One makes the token available through its own issuance mechanisms, while the other allows users to supply the token to a lending market.

The user does not need a stablecoin issued by the lending protocol itself for this interaction to work.

The ERC-20 token interface helps connect the two applications. DAI becomes a reusable building block that can be supported by multiple compatible protocols.

Example 4: Yield strategies built on existing protocols

Yield aggregators such as Yearn Finance illustrate how an application can combine several protocols into a higher-level investment product.

A user deposits a supported asset into a vault. Depending on the particular vault and strategy, the underlying assets may be deployed into lending markets, liquidity pools or other yield-generating opportunities.

The user interacts with the vault, while the strategy manages the underlying protocol interactions according to its rules.

The vault does not necessarily generate all the yield itself. It coordinates other services that may generate lending interest, trading fees or other returns.

This is composability at the product level: the developer creates a simpler user experience by combining existing financial infrastructure.

6. Forkability: When Developers Copy Instead of Connect

Composability has a closely related concept: forkability.

Because smart contract code is often publicly available, developers may be able to copy and adapt an existing implementation to launch a separate project, subject to the applicable licence.

This is different from composability.

• Composability means using existing deployed contracts as building blocks.
• Code reuse means copying or adapting an implementation.
• Forking means creating a separate project based on an existing project's code.

Consider the relationship between Uniswap and SushiSwap in 2020.

SushiSwap launched using a version of Uniswap's code and offered additional token incentives to attract liquidity providers. This strategy, commonly described as a "vampire attack," encouraged users to move liquidity from one protocol to another.

The episode illustrated an important characteristic of open infrastructure: a competitor can reproduce much of a product's underlying functionality without recreating it from scratch.

Copying code does not, however, copy the original protocol's liquidity, users, reputation or operating history.

A new deployment has its own contracts and state. It must attract users and liquidity, and its security must be evaluated independently.

For developers, this means that publishing code makes reuse easier, but it also lowers barriers to competition.

7. How Composability Fuelled Ethereum's Growth

Composability creates a network effect in which every new building block can make additional products easier to develop.

As tokens, exchanges and lending protocols became available, developers could combine them into applications that would have required much more infrastructure if built independently.

DeFi Summer, 2020

A prominent example was the period known as DeFi Summer in 2020.

By then, several building blocks had emerged, including stablecoins, Uniswap's decentralized exchange and lending protocols such as Compound and Aave.

Over the course of 2020, the value of assets locked in DeFi protocols grew from roughly $700 million at the start of the year to around $15 billion by December, according to DeFi Pulse.

In June 2020, Compound began distributing its COMP governance token to users participating in its lending markets. The model helped popularize liquidity mining, in which protocols distribute tokens to encourage users to supply assets or participate in a market.

Other projects adopted similar incentive mechanisms, while developers continued to combine existing protocols in new ways.

Yearn Finance, launched in 2020, became an example of an application that could coordinate existing lending services to pursue yield.

The broader lesson is that Ethereum's ecosystem did not grow solely because individual protocols became more capable. It also grew because developers could reuse and combine those capabilities.

8. Open Infrastructure Versus Traditional Walled Gardens

Composability changes the traditional platform business model.

Many internet businesses operate as walled gardens. They control their infrastructure, user data and access to their platforms. External businesses generally need permission, commercial agreements and technical integrations to connect.

Ethereum offers an alternative model in which public smart contracts can serve as shared infrastructure.

Open infrastructure does not mean every aspect of a business is public or permissionless. Applications may still use private interfaces, front ends, compliance checks or restricted contracts.

Nevertheless, the underlying model allows developers to build on existing services without requiring every service provider to approve the integration.

How do open protocols build lasting businesses?

If competitors can reuse the code, where does a protocol's competitive advantage come from?

• Liquidity and network effects: A trading service with deep liquidity can offer better execution, attracting more users and further liquidity. Copying its code does not automatically copy its deposits.
• Trust and track record: Users may prefer protocols with established security practices, independent audits and a long history of operation.
• Brand and user experience: Different applications can provide different interfaces to the same underlying contracts. A simpler, safer or more accessible experience can attract customers.
• Fees and services: Protocols and applications may charge fees for their services, depending on their design.
• Becoming infrastructure: A protocol that many other applications depend on can become difficult to replace because of its integrations and ecosystem relationships.

This resembles the open-source software model. Linux and Android demonstrate how open technologies can support large businesses, even when the underlying software is not exclusively controlled by one company.

Ethereum extends a similar idea to shared on-chain services that can interact with assets and financial positions.

9. Risks of Composability

Composability makes it easier to build complex applications, but it also creates dependencies. A problem in one component can affect every application that relies on it.

9.1 Shared dependencies

Suppose a lending application relies on a token, a price feed and a decentralized exchange developed by other teams.

Even if the lending application's own code works correctly, a vulnerability in one of those dependencies can expose its users to losses.

The application inherits risks from contracts that its developers may not be able to fix or control.

9.2 Contagion

Problems can spread through connected protocols.

Imagine a token widely used as collateral suddenly loses value. Lending protocols may liquidate collateral to protect themselves. If those sales push the token's price down further, additional positions may become eligible for liquidation.

The resulting pressure can spread to other applications that depend on the same token or related markets.

This is a form of financial contagion: connections that allow capital and functionality to move efficiently can also transmit stress across the ecosystem.

9.3 Price manipulation attacks

Composability can also be exploited when one contract relies on an unreliable source of information.

Consider this hypothetical attack:

1. An attacker obtains a large amount of temporary liquidity through a flash loan.
2. The attacker makes a large trade on a market with limited liquidity, temporarily distorting a token's price.
3. A lending protocol relies on that distorted price to value collateral.
4. The attacker uses the inflated valuation to borrow more assets than the collateral should support.
5. The attacker repays the flash loan and attempts to retain the proceeds.

The weakness is not necessarily in the lending contract's basic borrowing logic. The problem may be that it trusts a price source that can be manipulated.

Incidents involving bZx in early 2020 helped demonstrate how flash loans, market manipulation and lending mechanisms could interact in attacks.

This is why lending protocols need robust pricing mechanisms, appropriate collateral parameters and protections against manipulation.

9.4 Being copied

As the SushiSwap example illustrates, a successful protocol can be forked and offered with different incentives.

Businesses that rely solely on keeping their code unique may struggle to compete. As Section 8 discusses, lasting advantages come from security, liquidity, reputation and product quality.

9.5 Transaction ordering and token approvals

Two further risks arise from the way users and applications interact with composed contracts.

Transaction ordering: Pending transactions are visible before they are confirmed, and the order in which they are included can be influenced. Bots can exploit this, for example by placing trades immediately before and after a user's swap to profit from the price movement it causes, known as a "sandwich attack". Applications commonly reduce this risk with slippage limits or private transaction submission.

Token approvals: To let a contract move their tokens, users grant it an allowance. Many applications request unlimited allowances for convenience. If that contract is later exploited, attackers may be able to take tokens from every wallet that approved it. Limiting approvals to the amount needed and revoking unused approvals reduces this exposure.

Managing composability risk

Before building on an existing protocol, developers should consider:

• How long has the protocol operated, and how much value does it secure?
• Has the code been independently audited?
• Can the contract's rules be changed, and who has permission to change them?
• Where does the protocol obtain its prices and other external information?
• What happens to the application if one of its dependencies fails?
• Can competitors use the same building blocks, and what makes the new product different?
• Does the integration require users to grant large or unlimited token approvals?

10. What Does Composability Mean for Businesses?

For a business building on Ethereum, composability changes the traditional "build or buy" decision into three choices: build it, buy it, or plug into existing infrastructure.

Consider an Abu Dhabi-based freelancing platform that pays employees around the world.

Traditionally, the business might need banking partners in multiple countries, currency conversion arrangements and integrations with different payment systems.

Using Ethereum-based infrastructure, the platform could instead:

1. Accept client payments in USDC.
2. Hold the funds in an escrow smart contract until the work is approved.
3. Use an existing trading service to convert USDC into another supported token if an employee prefers it.
4. Potentially deploy eligible idle funds into a lending service, subject to the platform's legal, operational and risk requirements.

The platform would still need to build its own escrow rules, website, customer support and business processes. It would also need to address custody, security, regulatory compliance and the risks of the services it uses.

However, it would not need to develop every payment, trading and lending mechanism independently.

This allows the team to concentrate its resources on the features that distinguish its product.

Other potential applications include accepting stablecoin payments, converting assets automatically, using established price feeds and integrating blockchain-based naming services such as ENS.

Composability can therefore reduce development costs and time to market. At the same time, it requires businesses to assess the reliability and suitability of every external component they depend on.

11. Conclusion

Composability is one of the defining characteristics of Ethereum's smart contract ecosystem. It allows independently developed contracts to function as building blocks for new applications, enabling developers to create complex services without rebuilding every component from scratch.

Its importance extends beyond technical efficiency. Composability has helped shape DeFi's growth, enabled new financial products, and introduced an open infrastructure model in which businesses can compete without exclusively controlling the underlying technology.

However, openness also creates dependencies, security risks and the possibility of competitors copying successful implementations.

The central lesson is that Ethereum allows developers to build on each other's work. The strongest applications combine existing infrastructure with something valuable of their own: trust, security, a better user experience or a service that solves a specific problem.

Key Takeaways