(9) Composability Series: The Era of Soft Composability

Enabling ownership and trust between crypto native communities and their protocols

Up until now, blockchain applications have been built with “hard composability” - the assumption that any interaction between two parties must be completely hardcoded. On a technical level, that meant clearly defining everything functionally before deploying it into an immutable smart contract. A fun way of visualizing this is the contracts wizard by OpenZeppelin, where you have to choose all the combinations of options you want before deploying.

Today, we’re entering an era of “soft composability” where the exact interaction requirements can be integrated right before execution, and relies on some external feedback loop. This enables stronger connection and efficiency between the social layer and protocol layer, fundamentally changing how quickly communities and apps are built. We’ll look into how protocols like Jokerace, Farcaster/Bountycaster, points, ZK proofs/ML, and Uniswap v4 hooks all create flexibility and efficiency by relying more on “trust” within the social layer.

A Brief History of Protocols and Ownership

App protocols used to be:

• 1-Time Deploy: Contracts had all required logic included at the time of deployment, with long wait times before major upgrades or new versions were deployed.

• Shared Contracts: all interactions, tokens, parameters, permissions sit on one set of contracts - for all users. Such as Aave v2 controlling all listed tokens and risk parameters in a single lending pool; or Opensea/Foundation/Artblocks having all creator NFT collections and permissions listed on one shared contract.

• Single DAO/Entity Managed: ownership, upgrades, and executions go through only one entity. Usually some single governance contract.

In this time, the ecosystem settled on widely accepted and battle tested standards for tokens, lending pools, vaults, AMMs, governance, delegation, upgrades, marketplaces, aggregators, signatures and more. Most experiments/competition were forks that would tweak one or two things from the standard, make it more gas efficient, and then launch a token.

In 2021, we saw the rise of many DAOs outside of just the main protocol DAOs. With these DAOs, we experienced the inflexibility of having monolithic contracts. They wanted to be able to fully manage their own pools of liquidity, plug and play their own tokens, add/remove different functions, and assign owners at will.

Their needs led to four main trends playing out over the last bull/bear cycle:

• Hierarchical Permission Structures: hats protocol has taken “roles” much further so that you can more easily have a sub-dao structure. Argent has played with setting “guardians” for specific assets. Hierarchies were enforced on web2 platforms like discord/telegram with tools like guild.xyz.

• Additional Modules for Functionality: Instead of 1-time deploy governance models like aragon - now you could add “module” contracts for more advanced permissions and functions in the multisig/protocol/token. Some examples are the tribute framework, 0xRails, manifold extensions, and gnosis zodiac. More recently, this has evolved within account abstraction wallets that can add/remove signatories per function like the Visa/Gnosis Pay relay and safe modules.

• Creator Owned Tokens (Editions): For token contracts themselves, we saw everyone get their own contract deployed like “Editions” on Mirror and Zora, “Collections” on Foundation, and project engines on Artblocks. That meant they had a lot more control over their tokens.

• Community Owned Pools: At a protocol level, we saw the popularity of DAO managed liquidity with experiments like Olympus DAO and Fuse/Rari Capital. Oftentimes people wanted to spin up a DAO for accomplishing one thing. ConstitutionDAO led this, and became productized with protocols like PartyDAO and Juicebox. Liquidity became more intentional, and had specific goals.

tldr; in the “ownership” era of the last cycle, we saw many DAOs successfully gain control of their tokens, permissions, and protocols through modular contracts. These people were willing to break away from the traditional standards created during the “protocol” era.

Soft Composability and the Social Layer

Operations and development cycles have remained an issue for DAOs after the last cycle. DAOs tried way too hard to vote, hardcode, and automate every single thing (especially given 24KB contract size limits). Rewards, allowlists, integrations, partnerships - all were hardcoded into contracts. Every single action required a token, tokens were always liquid, and governance participation was/is a mess.

Put more simply, connecting the social layer of the community with the protocol layer was like trying to untangle electric cables at the world’s largest data center. I think we’ve finally agreed that not everything needs to be immutably connected onchain - it’s okay to rely on the inherent trust layer within a community to operate and iterate.

This “soft composability” through trust comes in three forms today:

• Social Coprocessing: We can interact with onchain protocols on-the-fly way with Dune query address allowlists in Jokerace contests and Rabbithole quests, chat based bounties using Bountycaster on farcaster, editable and evolving traits in Station groupos, and streamlined web2/web3 onboarding with Galxe. Even “points” gives us a loose way of tying together protocols, Rainbow points has technically tied together Metamask swaps and Rainbow swaps in a unique way offchain (with points productized with stackdotso). The exact conditions and inclusion are hardcoded onchain at the moment of execution, and can change at any given time.

• Verified Models: Verification and inferences can be added in at runtime using offchain compute in models and zk circuits, instead of hardcoding the requirements for an action at deploy time. This means that for an onchain function to run succesfully, the proof must pass. A simple application of this is in identity, whether that’s simple membership sets or complex aggregations of “proofs” Uniswap v4 swap hooks. Holding proofs will be analogous to holding tokens for membership - try creating some simple ID proofs yourself. This proof based world will continue to evolve with blockchain read/compute platforms like Axiom and Succinct, big data with Lagrange, and zkML using Modulus Labs and Ritual. Model alignment and upgrades for probabilistic inferences will happen in open format using platforms like spectral. You can learn more about the ZK/cryptography landscape in DC’s article.

• Social Backstops: It’s not always cost effective to verify a proof onchain for every single output, so instead a protocol could operate as if the input is trusted naturally - with the option for anyone to independently verify/contest the proofs if needed. We will see more and more optimistic proofs stored in data availability layers (and not just for rollups), where the proof data is then pruned every 18 to 30 days. There is trust that someone out there is keeping tabs and will contest in time if there is an error. I see this as a “backstop” approach, in an effort to gain higher cost/time efficiency in running protocols. Doing it this way is not any less secure on a technical level. An older example of “social backstops” are multisigs for chains and bridges, even if they continually get hacked. There have been interesting experiments such as Gnosis using a ZK prover as their 8th validator on their bridge, mixing human and machine trust.

For all of these, the actual contracts deployed contains generalized interfaces/functions for you to add or update social coprocessing, models, and backstops as needed. Altogether, this flexible set of integrations with a strong offchain feedback loop is what I think of as “soft composability”.

The “ownership” trends from earlier made it easier to launch a crypto native community/DAO, and these “soft composability” trends make it easier to operate and scale one.

What Comes Next?

Altogether, we’ve progressed somewhat like this:

In the new era, “soft composability” enables us to scale the onchain tools in tandem with the growth rate of any online community. This is happening hand in hand with the evolution of the modular stack, which enables much of this.

It’s natural that people feel uneasy during this time, as it seems at times that we are moving away from what we are used to tying to “decentralization” by relying more on inherent trust within the social layer. But we also know that crypto has and always will rely on social consensus more than any other technical tidbits - so I think these changes are inevitable at the application layer. Ultimately, these changes do not hinder the permissionless and censorship resistant nature of crypto.

I will also note that this development and learning is only happening in Ethereum right now. I think most other ecosystems - like Solana - are still in the “Protocol Era” of development.

Thanks to Data Always, David, Rajiv, and Garrett for their feedback on this article