Composability is useful because it lets users chain actions into one transaction, but each added protocol expands the attack surface. Security teams should treat every integration as a new trust boundary and test how failure in one component affects the whole flow. The main question is not whether composability is efficient, but whether the combined path remains safe under adversarial conditions.
Why composability changes the security model
In DeFi, composability is not just a convenience feature. The moment a transaction depends on several protocols, the security question shifts from “is each protocol acceptable on its own?” to “does the whole call chain still behave safely when any one component is stressed, mispriced, paused, manipulated, or partially broken?” That is a system-level question, not a single-contract question.
The practical implication is that each added hop introduces another trust assumption, another dependency on external state, and another place where timing, slippage, oracle inputs, approvals, or callback behavior can alter the final outcome. Even if every protocol is sound in isolation, the combined path may create a failure mode that none of the individual teams designed for.
Where combined transactions usually fail
The highest-risk failure modes are usually at the interface between protocols, especially where one step assumes the previous step succeeded safely and irreversibly. Common problems include stale or manipulated pricing, unexpected reentrancy-like behavior through callbacks, overly broad token approvals, fragile routing assumptions, and partial execution that leaves the user or treasury in an unsafe intermediate state.
Composability also creates dependency risk. If the transaction relies on a lending pool, DEX, bridge, oracle, or vault, then the security posture of the entire flow inherits the weakest operational assumption in that chain. For example, the safest local logic can still fail if downstream liquidity disappears, a limit is bypassed, or a protocol upgrade changes an interface in ways the integrator did not anticipate.
This is why protocol combination should be treated as adversarial choreography. A safe design is one where the team can explain the exact failure behavior of every step, including what happens if a call reverts, returns unexpected values, executes against manipulated state, or completes in a way that benefits an attacker more than the user.
What good composability review looks like
Security review should start with the transaction path itself, not with the branding of the protocols involved. Teams should map the full dependency chain, identify every external call, and define the assumption each step makes about asset state, permissions, and final settlement. If one protocol can change the meaning of a later step, that interaction deserves explicit threat modelling.
- Review the exact order of operations and ask which steps must be atomic.
- Check whether the transaction depends on approvals, price updates, or external callbacks that can be front-run or invalidated.
- Test failure cases where one protocol pauses, reverts, changes parameters, or returns edge-case values.
- Validate that slippage, min-out, and balance checks still protect the user after all protocol hops are combined.
- Prefer bounded permissions and narrow exposure over reusable approvals or open-ended routing.
For practitioners, the useful standard is not “does this integration work in the happy path?” but “what is the blast radius if any one component behaves adversarially or unexpectedly?”
Risk and Threat Considerations
Composability increases the attack surface because an attacker only needs one weak link, one bad dependency, or one unsafe interaction pattern to turn a multi-step flow into a loss event. The risk is amplified when teams reuse assumptions from one protocol inside another without testing the combined system under stress, manipulation, or partial failure.
Failure mechanism: An attacker can exploit timing gaps, oracle dependence, approval scope, or protocol interaction effects to corrupt one step and let the resulting state flow through the rest of the transaction.
Impact: The result can be mispriced execution, fund loss, broken invariants, unintended asset transfer, or a transaction that appears valid locally but becomes unsafe when evaluated as a complete sequence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 16 — Application Software Security | Composed DeFi transactions need secure design and testing of external interactions. |
| Recommendation — Test multi-protocol transaction paths for unsafe dependencies and edge-case failures before release. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | DeFi composition can be abused through exposed on-chain interfaces and flawed assumptions. |
| Recommendation — Hunt for exploit paths that abuse exposed transaction logic and weak interaction boundaries. | ||
| NIST CSF 2.0 | PR.AC — Access Control Management | Composability depends on bounded permissions and controlled authorization across integrated steps. |
| ID.RA — Risk Assessment | Teams must assess how combined protocol behavior changes system-level risk. | |
| Recommendation — Constrain approvals and permissions so each transaction step only has the access it needs. Assess the full transaction chain for compounded failure modes before enabling the integration. | ||
Practitioner Guidance
What to prioritise: Prioritise the interaction boundaries, not the individual protocol logos. The most important review question is whether the combined transaction preserves the safety property you actually care about, such as execution integrity, settlement correctness, or bounded loss.
What to verify: Verify the path under adverse conditions, including reverted steps, stale state, changed liquidity, and manipulated inputs. If you cannot describe the failure behavior in one sentence per step, the integration is not yet ready for production exposure.
Common mistake: Teams often overtrust modularity and under-test composition. A protocol can be secure as a standalone primitive and still be dangerous when paired with another protocol whose assumptions do not line up.
Practitioner takeaway: Treat composability as a security trade-off that must be earned, not assumed, and approve it only when the full transaction remains safe after the weakest dependency fails.
Related resources from NHI Mgmt Group
- How should security leaders think about accountability when detection engineering and incident response span multiple teams?
- How should security teams think about a compromised integration like Drift?
- Why do infostealers change the way IAM teams think about cloud security?
- How should security teams govern AI agents that can invoke multiple tools in one session?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
