Hey Travis — I’ve been sitting with your feedback for a few days now. You raised exactly the kind of foundational questions I hoped would emerge, and your critique helped me see that my original proposal was trying to do too much, too fast, with too little structure. But it was also always meant to be something built with others — so thank you again for stepping into that.
After sharing the initial version and speaking with a few folks, I decided to reshape the path of the proposal.
One major shift: we started receiving research proposals — clear, scoped, strategic, and directly aligned with Allo’s goals. Things like:
- Afo’s Global Mapping: mapping entry points for capital coordination across public and DAO systems
- Matter Patterns: building a semantic, interoperable layer between grants and preference expression
- EcoDrips: experimenting with programmable semantic logic for eco-credit funding
So the real question became:
How do we support and structure what’s already happening — without getting in the way?
That’s where this new Research Jars proposal comes in.
Proposals Are Centered
Your core critique — that the original model removed the proposal process — was spot on. That version leaned too hard on trust and informality.
This new design flips that:
This keeps it simple, visible, and trackable — a structured rhythm that doesn’t try to control everything.
Governance & Group Coordination
To keep it lean, I propose:
- Minimal engineering — use the current Cookie Jar contract
- Hats Protocol for managing access (in v1 as social layer, potentially onchain in v2)
- Proposal and voting via Snapshot or Gardens
- Prompt curation + evaluation by Allominati (or another trusted working group)
I’ve also been thinking alongside Allo’s 6-month focus:
Revenue-generating builds → some proposals are exploring monetizable patterns
Structure that directs capital to what matters → this system does that
Build the “onchain capital” category → this frames the research side of it
Empower working groups → this activates that layer
Manage treasury wisely → predictable caps, clear cycles, visible evaluation
To start, I suggest initial prompts focus on:
- Refining existing Allo tools
- Exploring revenue-generation models (e.g. the DeFi Cookie Jar proposal)
- Building shared knowledge infrastructure for Allo as a category
Two Jars, Clear Scopes
To start, I’m proposing two themed Cookie Jars, each aligned to a different kind of contribution:
1. Ontology Jar
For contributors working on shared language, schemas, and mental models that help us understand and evolve capital coordination.
Examples:
- Preference alignment frameworks (Matter Patterns)
- Theory of Change logic
- Interoperable grant schemas
- Mapping mechanism interdependencies
Guiding Lens:
Network Shared Value (NSV) — Does this work increase the coordination capacity of the Allo network?
→ Up to 5 contributors
→ 0.08 ETH/month
→ 3-month cycle
2. Mechanism Experiments Jar
For contributors testing mechanisms and tools in the field, using Allo or adjacent protocols.
Examples:
- AlloIRL deployments
- QF variants like Tunable QF
- Revenue-generating Cookie Jar structures
- Local coordination tools in Greenpill-style chapters
→ Up to 3 contributors
→ 0.2 ETH/month
→ 3-month cycle
Evaluation — Now and Later
Right now:
- Researchers are selected by governance
- They publish cookie notes (with links + reflections)
- We host an end-of-cycle community review
Later:
- Attestations
- Impact badges
- Futarchy-style PASS/FAIL tokens
- Attribution graphs
Deep Funding as a Future Layer
NSV gives us a compass — but we also need maps.
That’s where Deep Funding comes in.
It helps us see what work other work depends on — and fund upstream contributors accordingly.
In the Ontology Jar, someone might:
- Map the dependency graph of past and current proposals
- Assign credit weights to foundational work
- Propose recursive funding models or reputation overlays
This gives us a long-term pathway:
Fund the research → Track its use → Reward its foundations.
What I’d Still Love Input On
- What’s the right structure-to-flow ratio for early-stage research?
- Are monthly notes enough, or do we need peer checkpoints?
- What feedback loops would help make this more useful and aligned?
Next Steps (If Supported)
- Launch the initial proposal round
- Vote to select contributors
- Use Hats to manage roles (manual or onchain)
- Run a 3-month pilot
- Document learnings + iterate
Thanks again — your input has been instrumental in getting to this version.
Excited to hear your thoughts on what’s missing, unclear, or still questionable.