Last week, the teams behind Station, Turnkey and Privy teamed up to host the inaugural Onchain or Nowhere salon. Builders from companies actively pushing web3 forward gathered to share their insights, reflections, and frustrations around the current state of infrastructure and products in crypto.

Based on that conversation, we’ve summarized several new frameworks, principles, and challenges discussed by the attendees — some more controversial than others.

The salon is comprised of three sections: abstracting away crypto, autonomous networks, and composable data & uniquely web3.

Part I of this series is on “Abstracting away crypto.”

"Abstracting away crypto" is controversial due to security concerns, centralization risk, and complexity. Despite these controversies, the abstraction of crypto infrastructure can significantly increase accessibility and adoption.

Part I: Abstracting away crypto

The initial dicusssion on reducing user onboarding friction ultimately veered into a conversation about trust – where it’s placed and how explicitly aware users are in granting it.

In the worst cases, users place trust in bad actors or low-security platforms, services, or exchanges – and get rugged. Less obvious, often a user is “only” trusting that their wallet won’t push a malicious update. But is trustlessness the primary goal, or is it protecting users that we should care about? How would we build products differently depending on which of those two aims we prioritized?

These questions and others led our discussion to circle two new frameworks for trust in crypto:

1. Progressive user responsibility

2. Trust, but;

Progressive user responsibility

We have been building experiences that minimize trust in third parties because that’s what the crypto-native audience wants. But many of the builders at our salon had seen firsthand that building with total trustlessness as the goal is fundamentally at odds with accessible UX for newcomers. A recurring question in the group was how to design for these two very different audiences. One answer: “Maybe there are no universal interfaces. Instead, we have to cater to both audiences separately.”

Progressive user responsibility acknowledges that new users may not, in fact, be better off relying solely on themselves. Moreover, new wallets with little in them might be perfectly reasonable to keep in the care of a platform you trust a little.

Our discussion revealed that many dApps and other platforms are increasingly adopting these progressively trustless user onboarding experiences – holding users’ hands as they start out while nudging them towards owning more of their own security risk over time.

Product-wise, what can this look like? A few contributed examples from the group:

• Mint (free) NFTs to a custodial wallet initially, and push the user to withdraw to a self-custody wallet over time

• Allow users to self-select into familiar login experiences (e.g., email), and guide them towards connecting a self-custodial wallet over time with a combination of nudges and hard limits

• Offer key recovery services initially, with options for users that understand the risks to opt out

Trust, but…

“Don’t trust, verify” is a fine aspiration that is totally unrealistic in the context of products that regular consumers actually use. Add to that, is a newcomer to crypto really trustworthy? Does putting the onus for trust on inexperienced users really improve security outcomes?

Trustlessness is still the destination, but pragmatic builders are adding qualifiers that balance a realistic appraisal of the current status quo and its shortcomings.

A few ideas from salon participants around how we can implement “trust, but” that actually makes sense for users:

Trust, but let me verify.

A (modified) oldie but goodie. This may have different meanings in different contexts, but a few examples:

• Proof of reserves

• Verifiable code: Auditable, open source code

• HTTPS for crypto: HTTPS for crypto: Protocols and unfakeable public markers to help users ensure their funds are safe

Trust, but only people you know

One member of the group suggested primitives that allow users to put their trust in a friend who’s more experienced. This kind of ‘delegated’ structure may start to look more feasible as account abstraction gains traction.

Other iterations of this trust model we’d like to see:

• More social recovery primitives

• More trusted, public networks for social proof

Trust, but let me exit

Some users may not want to manage their own non-custodial wallets. Others may be perfectly comfortable trusting a platform up to their limits of value at risk. One way for product builders to balance usability with the ethos of trustlessness is to use the “Opt Out” path.

What that could look like:

• Custodial wallets that maintain the ability for user to export

• Granting the user a choice on whether to enable key recovery support

As we navigate the delicate balance between trust and accessibility, it's clear that the future of our ecosystem relies on not only maintaining the foundational values of decentralization and trustlessness, but also ensuring that our technology is approachable to new audiences. As we create new frameworks, introduce progressive user responsibility, and navigate the trust paradox, we are pushing the boundaries of what is possible in this space.

Onchain or Nowhere is a collective of cutting-edge product builders exploring new experiences unlocked by onchain mechanisms and infrastructure. Reach out to us if you wish to be part of these conversations, whether you agree or disagree, or have something to add.

The next salon awaits.