The problem SafeCap.xyz solves

On-chain crowdfunding is still too hard for most people. Even with decentralized protocols, launching a campaign typically means connecting an EOA, signing multiple transactions, and managing private keys—friction that keeps non-crypto-natives out. Meanwhile, most existing platforms (even those on Farcaster) don’t offer meaningful social primitives like NFTs as proof of participation, and outreach is still manual.

SafeCap solves this by making decentralized crowdfunding radically easy and social:

• Frictionless, Non-Custodial Campaign Creation:

  With SafeCap, campaign creators spin up a campaign wallet inside a Trusted Execution Environment (TEE) using CDP. There’s no need to connect an EOA or manage private keys, but users still retain non-custodial control. Campaign creation is a one-click, Web2-simple experience—without sacrificing security or decentralization.

• NFTs as Social Badges:

  Every donor receives an AI-generated NFT unique to the campaign—a digital badge that serves as both a receipt and a social signal. Unlike other on-chain crowdfunding tools (including those on Farcaster), SafeCap turns donations into composable, on-chain social objects that can be displayed, traded, or used as credentials.

• AgentKit-Powered Fundraising:

  SafeCap integrates CDP AgentKit, allowing campaign creators to deploy AI agents that proactively reach out to potential donors. Critically, donors can contribute directly to the agent—no need to navigate to a separate dApp or connect wallets. The agent handles the flow, and the donor receives their NFT instantly, streamlining the entire process.

In summary:

SafeCap removes the technical and UX barriers that have kept on-chain crowdfunding niche. It’s non-custodial, credibly neutral, and—thanks to TEE/CDP wallets and agent-driven flows—finally as easy and social as Web2, but with all the benefits of Web3.

Challenges we ran into

During development, we encountered several notable obstacles primarily related to working with the CDP wallet API v2 SDK that was still in alpha stage.

One significant limitation was that the CDP wallet API v2 SDK prohibited certain critical operations - for example, sending user operations from a smart account does not allow direct contract deployment. We had to develop workarounds, such as deploying factory contracts first and then invoking send user operations through those factory contracts to deploy the actual smart contracts.

Documentation and examples for the CDP wallet API v2 SDK were quite sparse, which meant we spent considerable time analyzing type definitions and reverse-engineering implementations to understand how everything worked. Often, we found ourselves relying on auto-generated documentation that sometimes contained inaccuracies, further complicating the development process.

The core challenge became determining what was actually possible within these constraints, validating our assumptions, and making strategic decisions about which features to prioritize given the time limitations and technical complexities. Despite these obstacles, we pushed forward and maximized what could be accomplished with the available tools, even though we were essentially building on infrastructure not yet ready for production.