# CaaS × Curator Studio × ERC-8185: How They Compose

## TL;DR

CaaS describes **where capital comes from** (embedded fee splits, yield skims, issuance redirects). Curator Studio is **how that capital gets allocated** (curated strategies, forks, governance). ERC-8185 is the **shared primitive** that resolves off-chain entities (GitHub repos, npm packages) to Ethereum addresses. Together they form a complete funding stack without requiring additional payment rails.

## The Stack

┌─────────────────────────────────────────────────┐
│ CAPITAL FORMATION (CaaS)                        │
│ Fee splits, yield skims, treasury allocations   │
│ ERC-20 transfer directly to strategy address    │
└──────────────────┬──────────────────────────────┘
                   │
                   │  transfer(strategyAddress, amount)
                   │
┌──────────────────▼──────────────────────────────┐
│ CAPITAL ALLOCATION (Curator Studio)             │
│ Strategy = pool address that receives funds     │
│ Curators define weighted allocation tables      │
│ Community forks, discusses, adjusts weights     │
│ distribute() → Warehouse → recipients claim     │
└──────────────────┬──────────────────────────────┘
                   │
                   │  resolve(github.com/ethereum/solidity) → 0x...
                   │
┌──────────────────▼──────────────────────────────┐
│ ENTITY RESOLUTION (ERC-8185)                    │
│ Maps GitHub repos, npm packages, etc.           │
│ to Ethereum addresses                           │
│ Permissionless registration, pluggable verify   │
└─────────────────────────────────────────────────┘

## How CaaS Capital Enters Curator Studio

CaaS defines multiple "funding surfaces" where capital can be captured. Curator Studio can receive from all of them through two mechanisms:

### 1. Direct Transfer (Fee Splits, Treasury Allocations)
A strategy address is a standard contract that accepts ERC-20 transfers and direct ETH. No special integration needed — any CaaS fee split mechanism can simply `transfer()` to the strategy address.

**Example:** Uniswap embeds a 0.01% fee split. On every swap, a portion is transferred to a Curator Strategy address. No deposit call, no approval flow. Just a transfer.

### 2. Yield Vaults (Yield Skims, Streaming)
For continuous yield-based funding (e.g. protocol treasury yield skims), Curator Studio supports yield vaults which require a `deposit()` call. This enables accounting for shares, time-weighted distributions, and programmatic yield capture.

**Example:** A protocol treasury deposits yield into a vault that gets wrapped by a Curator Studio YieldRedirector. The vault accumulates. `harvest()` is triggered periodically — funds flow to the warehouse, recipients claim.

| CaaS Surface | Mechanism | Curator Studio Entry |
|---|---|---|
| Transaction fee splits | Embedded at execution | Direct transfer to strategy address |
| Treasury allocations | Discretionary/governance | Direct transfer or vault deposit |
| Yield skims | Continuous from DeFi positions | Yield vault harvest |

## ERC-8185: The Shared Registry

Both CaaS and the Coordination Layer spec identify a **permissionless entity registry** as a foundational primitive. ERC-8185 is exactly this.

ERC-8185 integration into Curator Studio's strategy creation flow is a natural M3 candidate:
1. Curator creates a strategy
2. For each recipient, they enter an identifier: `github.com/ethereum/solidity`
3. ERC-8185 resolves this to an Ethereum address via pluggable verification
4. The strategy allocation table uses the resolved address

This means:
- **Recipients don't need to register first.** Funds accumulate in the warehouse. When a project registers their address via ERC-8185, they can claim.
- **Multiple strategies can reference the same entity.** ERC-8185 is the canonical source of truth for "who is this project."
- **CaaS profiles map to ERC-8185 entries.** The "Demand-side body" in the Coordination Layer spec (project name, repos, package IDs, payout addresses) is a superset of what ERC-8185 stores.

## Deep Funding as Allocation Signal

Deep Funding produces a **dependency graph with weights** — "of all the value Ethereum creates, X% is attributable to the Solidity compiler, Y% to OpenZeppelin, Z% to ethers.js."

This maps directly to a Curator Strategy allocation table:

Deep Funding output:
  ethereum/solidity     → 0.15 weight
  OpenZeppelin/contracts → 0.12 weight
  ethers-io/ethers.js   → 0.08 weight
  ...

Curator Strategy:
  allocations: [
    { recipient: resolve("github.com/ethereum/solidity"), weight: 15 },
    { recipient: resolve("github.com/OpenZeppelin/contracts"), weight: 12 },
    { recipient: resolve("github.com/ethers-io/ethers.js"), weight: 8 },
    ...
  ]

The opportunity: **auto-generate Curator Strategies from Deep Funding data.** A curator can take the algorithmically-derived weights as a starting point, then adjust based on human judgment. Others can fork and express different opinions. This is pluralism in practice — algorithmic weights as a floor, human curation as the differentiator.

## Why Not Drips?

Drips is a mature protocol for streaming and splitting ERC-20 tokens with built-in dependency propagation. We evaluated deep integration and chose a different path.

**Where Drips fits:** As a **funding source** (CaaS input). A Drips stream or one-time give can target a Curator Strategy address like any other ERC-20 transfer. No special integration needed.

**Why not deeper:**

| Concern | Detail |
|---|---|
| **Parallel identity systems** | Drips resolves GitHub repos to protocol-specific `bigint` account IDs via its RepoDriver — not standard Ethereum addresses. Deep integration would conflict with ERC-8185, which resolves entities to standard addresses usable across any protocol. |
| **Duplicate distribution layer** | Drips has its own splits + receiving flow with cycle-based timing. Curator Studio's `distribute() → warehouse → claim` pattern is simpler, has no weekly cycle constraint, and is already built. Running both creates confusion over which is canonical. |
| **200 recipient cap** | Drips splits lists max out at 200 entries. Dependency graphs from Deep Funding can exceed this. |
| **Architectural independence** | Curator Studio's value is the full stack: curation → allocation → distribution → entity resolution. Replacing distribution and resolution with Drips reduces Curator Studio to a curation UI on someone else's protocol. |

**The principle:** Curator Studio accepts funds from anywhere (including Drips) and distributes through its own warehouse. Drips is a valid upstream source, not a downstream dependency.

Drips does streaming + dependency splits. But Curator Studio already handles splits (allocation tables) and distribution (warehouse). Adding Drips introduces:
- An extra protocol layer with its own contracts, UI, and mental model
- Streaming complexity when most CaaS flows are periodic (fee splits accumulate, then distribute)
- Dependency on a separate team's roadmap

Curator Studio's `distribute() → warehouse → claim` pattern is simpler and already built. Streaming can be added later if needed, but the core use case (periodic distribution of accumulated fees) doesn't require it.

## Mapping to the Coordination Layer Spec

Kevin's Coordination Layer defines four primitives. Here's where each lands:

| Coordination Layer | Implementation |
|---|---|
| **Registry** | ERC-8185 — direct mapping. Permissionless entity registration with structured metadata. |
| **Intents** | Curator Strategies are a form of funding intent: "here's how I think capital should flow." Not 1:1 matching, but curated allocation — a different shape of intent. |
| **Messages** | Curator Studio discussions/proposals serve a similar function — community deliberation over allocation, not 1:1 negotiation. |
| **Deals** | Not applicable. Curator Studio is pooled allocation (many donors → curator → many recipients), not bilateral agreements. |

The Coordination Layer is a marketplace for 1:1 matching. Curator Studio is a pooled allocation mechanism. They're complementary layers, not competing ones. A Coordination Layer "Deal" could fund a Curator Strategy as its disbursement mechanism.

## Concrete Scenario: Uniswap Funds Its Dependencies

1. **CaaS:** Uniswap governance votes to embed a 0.01% fee split on all swaps. Revenue flows to a Curator Strategy address via direct ERC-20 transfer.
2. **Deep Funding:** Dependency graph shows Uniswap transitively depends on 200+ repos. Weights are computed algorithmically.
3. **Curator Studio:** A curator creates a "Uniswap Dependencies" strategy using Deep Funding weights as the starting allocation. Community members fork with alternative weightings. Uniswap governance selects the canonical strategy (or funds multiple).
4. **ERC-8185:** Each repo in the allocation table resolves to an ETH address. Projects that haven't registered yet have funds accumulating in the warehouse — claimable whenever they register.
5. **Distribution:** `distribute()` is triggered weekly. Funds flow from the strategy to the warehouse. Recipients claim at their convenience.

No new payment rails. No streaming complexity. No intermediaries. Just transfers → curated splits → warehouse → claim.

## Signal Layer: Measuring What Deserves Funding

CaaS identifies the need to "quantify fragility through objective metrics" (bus factor, audit recency, maintenance velocity) but doesn't define how to measure them. The [Proof of Resilience](https://hackmd.io/@carlb/proof-of-resilience) paper proposes four oracle-friendly metrics that fill this gap:

| Signal | What it measures | Why it's game-proof |
| -------------------- | -------------------------------------------------------- | -------------------------------------------------- |
| Fuzzing survival | Hours survived under adversarial input | Can't fake — code either crashes or it doesn't |
| Build determinism | Binary matches source across independent builds (SLSA 4) | Can't fake — cryptographic hash match or zero |
| Downstream stability | Stake-weighted revert rate from dependents | Sybil-resistant via reputation weighting |
| Patch velocity | Time from vulnerability report to verified release | Clock stops at shipped + verified, not just merged |

The key insight: unlike popularity metrics (stars, downloads) that collapse under optimization pressure (Goodhart's Law), these metrics improve when gamed. An agent optimizing for fuzzing score writes safer code. The incentive and the outcome point in the same direction.

Integration with Curator Studio: Deep Funding provides who to fund (dependency graph). [Proof of Resilience](https://hackmd.io/@carlb/proof-of-resilience) provides how much they deserve (quality score). A Curator Strategy could weight allocations as:

weight = dependency_importance × quality_score

A project that is critical in the dependency graph but scores low on security metrics gets flagged as underfunded risk — not rewarded for its fragility.

## Multi-Layer Capital Formation

A single user transaction can fund a Curator Strategy from multiple CaaS surfaces simultaneously. From the CaaS blog post example — a $100 swap:

- **Application layer:** $0.1 MEV rebate redirect → strategy address
- **Smart contract layer:** $2 fee split → strategy address
- **Consensus layer:** 0.001 ETH from block reward → strategy address

Total: ~$2.10 + 0.001 ETH per swap, all landing in the same strategy via standard ERC-20 transfers. No custom integration per surface — a strategy address is just an address.

## Answers to Coordination Layer Open Questions

**#3 Cold Start:** Curator Studio + ERC-8185 can bootstrap from existing ecosystem data. Deep Funding and OSO provide dependency graphs with weights — these can auto-generate initial Curator Strategies. ERC-8185 can pre-register entities from OSO, Gitcoin, and EF grant recipient lists. Day one has real data, not empty registries.

**#8 Coalitional Funding (N:M Deals):** Curator Studio already solves this. A strategy is N:M by design — many donors fund the same strategy, many recipients receive from it. No multi-party signature collection needed. Donors express alignment by funding a strategy; recipients are in the allocation table. Kevin flags this as an open problem in the Coordination Layer spec; Curator Studio has the answer.

## Open Questions

1. **Auto-generate strategies from Deep Funding:** What's the integration surface? Can we consume their weight output programmatically?
2. **CaaS resilience metrics (bus factor, audit recency):** Could these signal-weight Curator Strategies, or are they better as separate data in the ERC-8185 profile?
3. **Multi-strategy funding:** A single CaaS source (e.g. Uniswap) might fund multiple competing strategies. How does governance select which strategies receive the fee split?
4. **Coordination Layer interop:** Could a Coordination Layer "Deal" specify a Curator Strategy as the disbursement target? 1:1 deal → pooled allocation.