Concepts
Mental model for Curator Studio — strategies, allocations, warehouse, yield, ENS, and social layer
Concepts
Curator Studio is built on a small set of composable primitives. This page explains the mental model. For precise behavior, see Requirements.
Strategies
A Strategy is a smart contract that defines weighted allocation rules. It accepts funds (ERC-20 or ETH), holds them until distribution, and then routes them to recipients via the SplitsWarehouse. The strategy owner can rebalance allocations but cannot withdraw funds — this is the core non-custodial property.
Strategies can be forked to create variations. Forks track lineage for attribution, discovery, and reputation building.
Allocations
Each allocation has a recipient (any Ethereum address), a weight (relative share), and a label (human-readable name).
Weights are not percentages — each recipient's share is weight / totalWeight. This means adding a new recipient doesn't require recalculating existing weights:
| Allocations | Resulting split |
|---|---|
{A: 1, B: 1} | 50% / 50% |
{A: 1, B: 1, C: 1} | 33% / 33% / 33% |
{A: 7, B: 3} | 70% / 30% |
Curator fees are regular allocations. There's no special fee mechanism — the curator simply adds their own address as a recipient. This makes fees fully transparent and auditable.
SplitsWarehouse
The warehouse is a shared ERC-6909 multi-token vault (from 0xSplits) where distributed funds accumulate. It uses a pull model: recipients withdraw when ready, rather than receiving direct transfers during distribution.
Why pull instead of push?
- Gas efficient — one batch deposit instead of N individual transfers
- Failure isolated — a reverting recipient doesn't block other recipients
- Convenient — recipients accumulate from multiple strategies and claim in one place
Yield Redirector
The YieldRedirector4626 wraps any ERC-4626 vault (Morpho, Euler, Yearn) and redirects only the yield to a Strategy, while preserving the depositor's principal.
Capital Provider → YieldRedirector → Source Vault (earns yield)
│
harvest() skims yield
│
▼
Strategy → distribute() → Warehouse → RecipientsThe depositor can withdraw their principal at any time. Only the yield — the surplus above principal — gets harvested and distributed. This enables endowment-style perpetual funding without capital depletion.
Example: a 10M DAI treasury allocation. Deposit to a YieldRedirector wrapping sDAI (Spark, ~5% APY). That's ~500k DAI/year in yield harvested into a Strategy and routed to recipients, while the 10M principal remains fully withdrawable at any time — the model Protocol Guild pioneered, made permissionless and composable.
Fund-of-Funds
Strategies can allocate to other strategies, creating hierarchical curation:
Ecosystem Fund
├── 50% → Infrastructure Strategy
│ ├── 60% → Protocol Guild
│ └── 40% → Client Teams
├── 30% → Developer Tooling Strategy
│ ├── 50% → Foundry/Hardhat
│ └── 50% → Auditing Tools
└── 20% → Research StrategyEach level distributes independently. Curators at each level express domain expertise. Capital providers choose entry points matching their values.
ENS Integration
Strategies can register subdomains under the tenant's ENS namespace (e.g., opensource.support.eth for the support.eth tenant) for human-readable addresses. Donors can send funds to the ENS name from any compatible wallet instead of copying a hex address. ENS names can be set during strategy creation or connected to existing strategies later.
Tenants
A tenant is an independent operator that deploys its own StrategyFactory and owns its own ENS namespace. Tenants share the same protocol contracts and indexer infrastructure but maintain separate strategy namespaces, ENS domains, and factory addresses. support.eth is the first tenant.
The active tenant is configured at the application level via NEXT_PUBLIC_TENANT. The SDK resolves factory addresses, ENS domains, and indexer filters automatically from the tenant registry.
Design Principles
| Principle | Implementation |
|---|---|
| Non-custodial | Strategies have no withdrawal function — funds can only flow to configured recipients via warehouse |
| Permissionless | Anyone can create strategies, fund them, or trigger distributions. No gatekeepers. |
| Transparent | All allocations on-chain. All distributions indexed. Fees visible as regular allocations. |
| Composable | Strategies nest (fund-of-funds). ERC-4626 yield vaults. ERC-6909 warehouse. ENS naming. |
| Credibly neutral | No admin keys. No upgrade authority. Owner can only rebalance, never extract. |
Drafts
A Draft is an off-chain strategy proposal. Curators author allocations — choosing recipients and weights — without deploying anything on-chain. Drafts can be private (only visible to the author), unlisted (accessible by link), or public (discoverable by everyone). When a draft is ready, the curator publishes it as an on-chain strategy.
Drafts lower the barrier to curation: experiment with allocations, gather feedback, and only pay gas when you're confident. Drafts can also be forked to create merge proposals.
Every edit to a draft creates an immutable version snapshot, building a complete history of how allocations evolved over time. Version history is visible to collaborators and preserved after publishing.
Comments & Reactions
Strategies and drafts support threaded comments and emoji reactions. Comments can include inline allocation diffs — proposed changes to recipient weights rendered as before/after comparisons — turning discussion into actionable suggestions.
alice.eth commented on "Open Source Fund":
"We should increase Protocol Guild's share."
Proposed diff:
Protocol Guild 40% → 55%
Client Teams 60% → 45%
👍 3 🔥 1Merge Proposals
A merge proposal is a fork of a draft with modified allocations, submitted back to the original author for review. The owner sees a diff of the proposed changes and can accept (which triggers a rebalance to the new allocations) or decline.
pending → accepted (rebalance triggered)
→ declinedThis gives strategies a lightweight governance loop: anyone can propose changes, but only the owner decides what ships.
Notifications
Curators receive an activity feed tracking comments, reactions, and merge proposals on their strategies and drafts. Notifications use a polling model — the client fetches unread activity periodically rather than relying on push delivery.
Authentication
Write operations — creating drafts, posting comments, reacting, submitting proposals — require authentication. Curator Studio uses Sign-In With Ethereum (SIWE) via BetterAuth. The web app issues JWTs on sign-in; the indexer API verifies them via JWKS. Read operations remain unauthenticated.
Curator Profiles
Every Ethereum address has a curator profile page aggregating its on-chain strategies and off-chain drafts. The profile includes curator stats — strategy count, draft count, times forked, and total funds distributed — giving a quick snapshot of a curator's impact. Curator addresses throughout the app are clickable links to these profiles, making it easy to explore a curator's body of work and reputation.