The Tension
As builders shipping production code on Stacks, we’re increasingly running into a pattern that deserves ecosystem-wide discussion: contract-caller gating as the default security posture.
This isn’t a critique of any specific protocol or auditor. It’s an invitation to collectively examine a tradeoff that will compound as our ecosystem grows.
The Pattern
Many audited Stacks protocols enforce strict contract-caller checks—ensuring only direct calls (or whitelisted contracts) can interact with core functions. The rationale is sound: it eliminates proxy contract attack vectors where a malicious intermediary could manipulate state or exploit tx-sender assumptions.
Security auditors—rightfully conservative—often recommend this approach. And for a protocol’s base layer, especially at launch, “better safe than sorry” makes sense.
The Cost
Here’s what this means for builders creating composable layers:
Instead of 1 extension contract serving N smart wallets, you embed the same logic into all N smart wallet contracts.
Want to build a smart wallet contract that interacts with Protocol A? You need Protocol A’s blessing or you duplicate their interface internally. Want to add the same functionality for a different collateral type (e.g., stSTX instead of sBTC)? New contract. New audit. Same code.
The ecosystem pays a compounding tax in duplicated code every time someone builds on top of restricted protocols.
This friction isn’t theoretical. Builders working on smart wallets, aggregators, and composable DeFi layers are hitting this wall today.
The Core Question
Should individual protocols absorb responsibility for proxy contract attacks, or should that responsibility live elsewhere?
Some possibilities worth exploring:
-
Clarity 4 post-conditions: Contract-level post-conditions and contract hash verification may provide sufficient security guarantees without sacrificing composability. Are we underutilizing these primitives?
-
Whitelisting patterns: Similar to PoX’s approach—protocols could allow trait-based whitelisting where wallets register approved extensions. Not perfect, but more flexible than blanket restrictions.
-
Layered security postures: Conservative base layer + more permissive “advanced” entry points for verified integrators. Let protocols offer both.
-
Ecosystem-wide standards: If every protocol independently gates on contract-caller, we’ve collectively decided composability isn’t a priority. Is that the ecosystem we want?
Why This Matters Now
Stacks is positioning for exponential growth. The decisions we encode today—in contracts and in audit recommendations—will shape what’s possible tomorrow.
Smart wallet contracts, account abstraction, DeFi aggregators, automated strategy vaults… these all depend on contracts being able to compose. If our default security posture makes composition painful, we’re limiting our own ceiling.
Not Asking for Less Security
To be clear: proxy contract attacks are real. tx-sender auth has genuine edge cases. Auditors recommending caution aren’t wrong.
But courageous product decisions that push back on excessive caution—when the tradeoff is ecosystem-wide composability—can pay off long-term.
Maybe there’s a path that preserves both.
Discussion
-
What’s your experience building composable layers on Stacks?
-
Are Clarity 4 post-conditions sufficient to relax contract-caller restrictions safely?
-
Should we develop ecosystem standards for “composability-friendly” security patterns?
-
How do other ecosystems handle this tension?
Curious to hear from protocol teams, auditors, and builders who’ve felt this friction firsthand.
This post reflects conversations with multiple builders and is intended to spark productive discussion, not criticize any specific team’s decisions. Security-first launches are valid. The question is what comes next.
