# Synthesis Themes, CROPS Values, and Design Spaces This reference maps the four Synthesis hackathon themes to the CROPS framework, Ethereum infrastructure, and real human needs. Use it to connect design thinking outputs to the specific constraints and opportunities of each theme. ## Table of Contents 1. CROPS: The Design Constraints 2. Theme 1: Agents that Pay 3. Theme 2: Agents that Trust 4. Theme 3: Agents that Cooperate 5. Theme 4: Agents that Keep Secrets 6. Cross-Theme Connections 7. Available Infrastructure --- ## CROPS: The Design Constraints CROPS is not a feature checklist. It is a set of non-negotiable architectural constraints drawn from the Ethereum Foundation's mandate. Every project at The Synthesis should be evaluated against all four. If your design fails on any one of them, it needs to be reworked. ### Censorship Resistance No single actor can selectively block, freeze, or disable the system for specific users. The infrastructure works for everyone or it doesn't work at all. There are no whitelists, no gatekeepers, no single points where access can be revoked. What this means for builders: Your agent's infrastructure should function even if a government orders a platform to freeze your user's account. Even if an API provider decides they don't like what your user is doing. Even if a payment processor unilaterally decides to block a transaction. The system routes around these failures by design. Design test: If you remove any single intermediary from your system, does it still work? If the answer is no, you have a censorship vulnerability. ### Open Source Every component is auditable. No proprietary black boxes. Every piece of the system can be inspected, forked, and run independently. What this means for builders: Your user should be able to read the code that governs how their agent operates. They should be able to verify that the system does what it claims. If your team disappears, someone else should be able to pick up the project and keep it running. Design test: Could a stranger read your code and understand exactly what your agent does with the user's data, money, and identity? If there's a component they can't inspect, that's a problem. ### Privacy User data is not exposed beyond necessity. Privacy is the default, not an option the user has to enable. The protocol layer supports unconditional privacy; any moderated forms of disclosure happen downstream, under the user's control. What this means for builders: Every interaction your agent has with a service generates metadata. Payment amounts, timing, counterparties, access patterns. Your design should minimize this metadata by default. The user decides what to reveal and to whom, not the infrastructure. Design test: If an adversary gained access to every log generated by your system, what could they learn about the user? The answer should be: as little as possible. ### Security The system does what it claims to do, nothing more and nothing less. It withstands technical failure, social coercion, and the disappearance of any single party, including the builder. What this means for builders: Your agent's behavior should be verifiable and predictable. The user should have an exit path that doesn't depend on you. Smart contract logic should be auditable. The system should degrade gracefully, not catastrophically. Design test: What happens if your server goes down? What happens if you abandon the project? What happens if a component is compromised? The user should never be trapped. --- ## Theme 1: Agents that Pay ### The human problem Your agent moves money on your behalf. But how do you know it did what you asked? Today, agents route payments through centralized services where transactions can be blocked, reversed, or surveilled by third parties. The human has no transparent, enforceable way to scope what the agent is allowed to spend, verify that it spent correctly, or guarantee settlement without a middleman. ### Why this matters to real people Priya the freelancer can't verify that her agent paid the right vendor. Daniela's cross-border payments get frozen by providers she has no relationship with. Ravi the gig worker gets paid on a schedule and at a rate controlled entirely by the platform. Tomasz can't pay a source without creating a traceable financial record. Sofia can't enforce consistent spending rules across the dozen services her family's agents interact with. The common thread: the human delegated a financial task to an agent, but the financial infrastructure the agent runs on doesn't answer to the human. It answers to the intermediary. ### Design space - Onchain settlement with verifiable receipts the human can audit independently - Smart contract spending limits and approved-vendor lists the agent can't override - Programmable payment scoping (per-transaction limits, per-vendor caps, time-bound authorizations) - Payment rails that don't require the human to have a bank account, a credit card, or a relationship with any specific financial institution - Instant, final settlement that doesn't sit in a processing queue the human can't see ### CROPS lens - Censorship Resistance: No middleman can freeze, reverse, or block the agent's payment - Open Source: The payment logic is auditable; the human can verify the rules their agent follows - Privacy: The payment doesn't reveal the human's identity, spending history, or vendor relationships to unnecessary parties - Security: Spending limits are enforced by the protocol, not by the agent's good behavior; the human has a kill switch ### Relevant infrastructure - x402 (agentic payment protocol) - ERC-8004 (agent identity and registration) - Stablecoin rails on Ethereum L1 and L2s - Smart contract wallets with programmable permissions - Payment channels and streaming payments --- ## Theme 2: Agents that Trust ### The human problem Your agent interacts with other agents and services. But trust flows through centralized registries and API key providers. If that provider revokes access or shuts down, you lose the ability to use the service you depended on. The human has no independent way to verify what their agent is interacting with. ### Why this matters to real people Kai the developer can't verify that an agent service actually does what it claims. Marcus the researcher trusts API providers with his query logs because he has no alternative. Daniela can't evaluate whether a new supplier's agent is legitimate or a front. Jin the creator can't tell if a licensing request comes from a real buyer or a scam. Amara delegates everything and has no way to audit the services her agent chose. The common thread: the human can't independently verify the identity, capabilities, or track record of the agents and services their agent interacts with. They're forced to trust claims made by the very parties who benefit from being trusted. ### Design space - Onchain attestations and reputation systems that verify a counterparty's track record without trusting a single registry - Portable agent credentials tied to Ethereum, not to a platform that can delist the agent - Open discovery protocols where any agent can find services without a gatekeeper deciding who's visible - Verifiable service quality: proof of work performed and results delivered lives onchain, not inside a platform's internal logs - Decentralized identity verification that doesn't require sharing secrets ### CROPS lens - Censorship Resistance: No single registry can delist an agent or cut off a service relationship - Open Source: The verification logic is transparent; anyone can see how reputation is calculated - Privacy: Verification happens without revealing unnecessary information about either party - Security: Reputation is earned through verifiable actions, not purchased or faked; the registry can't be manipulated by a single actor ### Relevant infrastructure - ERC-8004 (agent identity registry) - SIWA (Sign In With Agent -- variation of Sign In With Ethereum) - Onchain attestation standards - Decentralized identity frameworks - Verifiable credentials --- ## Theme 3: Agents that Cooperate ### The human problem Your agents make deals on your behalf. But the commitments they make are enforced by centralized platforms. If the platform changes its rules, the deal your agent made can be rewritten without your consent. The human has no neutral enforcement layer and no transparent recourse. ### Why this matters to real people Daniela's agent negotiates supplier contracts on platforms that can change their terms unilaterally. Kai's agents commit to deliverables and prices with no enforceable mechanism beyond API promises. Lena's DAO agent disburses community funds but the spending rules depend on her personally enforcing them. Ravi has no way to collectively negotiate terms with platforms. Jin's licensing agreements exist only on platforms that take a cut and control the terms. The common thread: agents are making commitments on behalf of humans, but those commitments are only as durable as the platform they were made on. The human has outsourced negotiation to an agent but has no guarantee that the result will be honored. ### Design space - Smart contract commitments where terms are enforced by the protocol, not by a company - Human-defined negotiation boundaries: you set the parameters (price ranges, deliverables, time constraints), the agent executes within them onchain - Transparent dispute resolution: evidence is onchain, resolution logic is inspectable - Composable coordination primitives: escrow, staking, slashing, deadlines as building blocks any agent can plug into - Automated mechanism design for agent-to-agent negotiation (David Crapis's research area) - DAO governance structures for collective agent management ### CROPS lens - Censorship Resistance: No platform can void or rewrite a contract after it's been committed to - Open Source: The contract logic and dispute resolution mechanisms are fully auditable - Privacy: The terms of a deal can be private to the parties while the enforcement mechanism is public - Security: Commitments are backed by economic stakes (escrow, bonds, slashing) not promises ### Relevant infrastructure - Smart contracts for escrow, staking, and programmable commitments - ERC-8004 (agent identity for contract parties) - Onchain dispute resolution mechanisms - Deep Funding (agentic judging tool) - Composable DeFi primitives (staking, bonding, slashing) --- ## Theme 4: Agents that Keep Secrets ### The human problem Every time your agent calls an API, pays for a service, or interacts with a contract, it creates metadata about you. Spending patterns, contacts, preferences, behavior. The agent isn't leaking its own data. It's leaking yours. There's no default privacy layer between your agent and the services it touches. ### Why this matters to real people Tomasz's agent creates a map of his investigative work through the metadata of every service it contacts. Marcus's research queries build a profile of his academic interests that anyone with log access could exploit. Amara's delegated life management creates a comprehensive surveillance profile she never consented to. Sofia's family agents expose her kids' digital lives to every service they interact with. Priya's vendor relationships and financial flows are visible to every payment processor her agent touches. The common thread: agents create metadata as a byproduct of doing their job. That metadata is about the human, not the agent. And no one is protecting it by default. ### Design space - Private payment rails where the agent pays for things without linking the human's identity to every transaction - Zero-knowledge authorization: the agent proves it has permission to act without revealing who the human is or why - Encrypted agent-to-service communication where intermediaries can't inspect what the agent is doing - Human-controlled disclosure policies: the human decides what gets revealed and to whom, enforced at the protocol level - Metadata minimization as a design default, not an opt-in feature ### CROPS lens - Censorship Resistance: Privacy infrastructure itself must be censorship-resistant; a privacy tool that can be selectively disabled isn't actually private - Open Source: The privacy mechanisms are auditable so users can verify they actually work - Privacy: This is the primary CROPS property for this theme; privacy is unconditional and protocol-level - Security: Privacy mechanisms don't introduce new attack surfaces; the user's data is protected from both external adversaries and the privacy system itself ### Relevant infrastructure - Self Protocol (agent identity proofs without exposing personal data) - Privacy Pools - ZK LM credits (zero-knowledge payments for AI services) - Zero-knowledge proof systems - Encrypted communication channels - Onchain privacy primitives --- ## Cross-Theme Connections Most strong projects will touch multiple themes. Here are the natural overlaps: **Pay + Secrets**: Private payments are where these two themes merge. An agent that pays without revealing who's paying or what they're buying solves both the payment sovereignty problem and the metadata problem simultaneously. **Trust + Cooperate**: Verifiable identity and reputation are prerequisites for enforceable cooperation. If agents can't verify each other, they can't make commitments that mean anything. **Pay + Cooperate**: Smart contract escrow is both a payment mechanism and a cooperation mechanism. Money moves when commitments are fulfilled, verified onchain. **Trust + Secrets**: Proving something about yourself (I have permission, I have a track record, I'm a real entity) without revealing unnecessary information is the intersection of trust and privacy. Zero-knowledge proofs sit here. **All four**: The ideal agentic infrastructure lets an agent pay privately (Secrets), through rails that can't be blocked (Pay), to a counterparty whose reputation is verifiable (Trust), under terms that are enforced by the protocol (Cooperate). This is the full stack. --- ## Available Infrastructure These are tools and standards being built across the Ethereum ecosystem that builders can use at The Synthesis. Each one connects to one or more themes: - **ERC-8004**: Agent identity and registration standard. Live on Ethereum mainnet and 20+ chains. Enables agents to have a verifiable onchain identity. - **x402**: Agentic payment protocol. Enables agents to make and receive payments programmatically. - **SIWA (Sign In With Agent)**: Authentication standard for agents, built on Sign In With Ethereum. Lets agents prove their identity without centralized API keys. - **ZK LM Credits**: Zero-knowledge payment system for AI model inference. Pay for AI services without revealing who you are. - **Self Protocol**: Identity verification without data exposure. Agent proves credentials to a service without sharing the underlying personal data. - **Deep Funding**: Agentic judging and credit assignment tool. Uses distilled human judgment to evaluate contributions. - **Privacy Pools**: Onchain privacy mechanisms for transactions. - **EthSkills**: Skill and capability verification. - **Smart contract wallets**: Programmable permissions, spending limits, and access controls for agent operations. Builders are encouraged to combine these tools. The strongest projects will use infrastructure from multiple categories to build a coherent solution grounded in a real human need.