How it works
Who’s funding what on Ethereum, and where to apply.
RFP Hub lists grants, hackathons, bounties and RFPs from any organization building on Ethereum. No applications are reviewed here. Every listing points to the program’s own site.
What it is
A public index. Programs run their own intake.
Every listing points back to the program’s own site. The data is open: exported nightly as JSON and CSV under CC0, and readable through the API.
Any organization can be listed, and verified publishers manage their own listings directly. No one here decides who gets funded.
If you’re building
Search, read, leave
- Searchby topic, org, city, type or award
- Read the listingaward, deadline, eligibility, references
- Apply on the program’s sitethis is where RFP Hub hands off
No account needed. Open the directory
If you run a program
Log in, submit, publish
- Log increates your account the first time
- Submit a listingreviewed against the public criteria
- Get verifiedthen your account publishes instantly
Already listed? Open it in the directory and claim it.
Read the rules. The full spec: five roles and what each may do, namespaces, review criteria, governance and the export schema.
The words this site uses
The words this site uses
- Opportunity
- The thing in the world: a grant round, a hackathon, a bounty, an RFP.
- Listing
- An opportunity as published here. Everything in the directory is a listing.
- Submission
- A listing that has been filed but not yet published. Only its submitter, its organization and Hub staff can see one.
- Namespace
- The part of an id before the colon. In
acme:round-4, that isacme. It names the organization a listing is published under.
The five roles
- Visitor
- Reads and applies without an account. This is most people, and the whole point of the site.
- Submitter
- Any signed-in account. Submits opportunities and edits its own. Everything it files waits for a decision, even a listing about a program you run, and five can be waiting at a time.
- Organization member
- An account a reviewer has attached to an organization. Sees everything filed in that organization’s name, published or not. If the organization is verified, its members publish into its namespace instantly. They also approve or reject what anybody else files there.
- Hub reviewer
- Staff, and deliberately organization-agnostic: works every queue, in every namespace, including the ones they belong to and the ones they compete with. The only role that verifies organizations, grants memberships, and settles claims and duplicates.
- Hub admin
- Everything a reviewer can do, plus the accounts themselves: who holds which role, who may create API keys, and the maintenance jobs.
Who can do what
Who can do what
A dot is an unqualified yes. A phrase is a real limit, and the limits are the interesting part. Every row describes what the API enforces. This page only describes that.
| Action | Visitor | Submitter | Verified org member | Hub reviewer | Hub admin |
|---|---|---|---|---|---|
| Anybody, without an account | |||||
| Read the directory and open any listing No account, and no record of who read what. | yes | yes | yes | yes | yes |
| Apply to a program Always on the program's own site. | yes | yes | yes | yes | yes |
| Download the data | yes | yes | yes | yes | yes |
| Getting something listed | |||||
| Submit an opportunity | no | yes | yes | yes | yes |
| Have more than five submissions waiting at once Five undecided at a time without one. A slot frees when one is decided. | no | no | yes | yes | yes |
| Edit a listing | no | own | own namespace | yes | yes |
| See listings that are not published yet | no | own | own namespace | yes | yes |
| Publish without review A listing whose id is in a verified organization's namespace goes live on submission. | no | no | own namespace | yes | yes |
| Approve a pending submission In its own namespace, that is the organization endorsing it, in its own name. | no | no | own namespace | yes | yes |
| Reject a submission Always with a written reason, and always under the name of whoever decided. | no | no | own namespace | yes | yes |
| Claim a listing for an organization Asks for an existing listing to move into your organization. | no | yes | yes | yes | yes |
| Hub-only decisions | |||||
| Decide a claim | no | no | no | yes | yes |
| Decide a suspected duplicate Confirm and merge into one listing, or dismiss. | no | no | no | yes | yes |
| Verify an organization The decision that turns an organization's submissions into instant publications. | no | no | no | yes | yes |
| Grant somebody membership of an organization | no | no | no | yes | yes |
| Change an account's role | no | no | no | no | yes |
| Run a maintenance job by hand Deadline sweeps, source verification, duplicate detection. | no | no | no | no | yes |
What "verified" means
What “verified” means, and what it does not
Verification says a reviewer is satisfied that an organization’s members speak for it. It is not an endorsement of the program, a check that its amounts are real, or a statement that it is a good place to apply.
Separately, the Hub runs a low-bar anti-spam check: the application page exists and its title is about the same program. Link looks right means only that. No amount, deadline or eligibility rule here has been verified. Read the program’s own page before you spend a week applying.
Why it works this way
Why it works this way
A verified organization decides what publishes in its own namespace. It approves or rejects whatever anybody files there. Everything past its own namespace stays with Hub staff.
Why an organization decides in its own namespace
A verified organization decides what publishes in its own namespace. Say somebody outside the organization files a listing about your program. A member approves it, the organization saying yes, this is ours and it is right, or rejects it. Nobody is better placed to know.
Decisions in your organization’s name carry your name. A rejection needs a written reason, and both the reason and the handle of the member who wrote it go into the listing’s history, which anybody can read. That is the whole safeguard, and it is deliberately the only one: an organization that can quietly bury an accurate listing about itself is a problem, and an organization that has to say why, in public, under a name, is not.
Why four powers stay with Hub staff
Everything past your own namespace stays with Hub staff. Verifying an organization, granting somebody membership of one, settling a claim over who owns a listing, deciding which of two near-identical listings survives — those are the four powers that could be used to widen a namespace’s own reach, so they sit with people who have no stake in any of them. Reviewers are Hub staff rather than delegates precisely so that a reviewer decides on programs they compete with by the same rule as on programs they have never heard of.
Why five submissions at a time
An account with no verified membership can hold five submissions awaiting a decision. A slot frees as soon as one is decided, either by a Hub reviewer or by the organization the listing names.
It keeps the queue honest. A queue anybody can fill without limit is a queue where the careful submission behind forty careless ones waits weeks for a person to reach it, and the first thing that goes is the review itself. Five is enough to file a whole grants program in one sitting, and few enough that everything in the queue is something somebody meant.
The data is yours
The data is yours
Everything published here is available as bulk JSON and CSV exports and Atom and RSS feeds, under the same open standard the site itself uses — no scraping-required tier and no paid export.
How decisions are made
How decisions are made
Every rule on this page describes what the API actually enforces; the project’s governance framework covers who gets to change those rules, what one listing is checked against before it publishes, how a proposed change to the Standard itself gets reviewed, and what happens when somebody disagrees with a decision.