Coordinape

• Name: Coordinape
• URL: https://coordinape.com/
• Category: peer-recognition payroll infrastructure / contribution-legibility system / onchain reputation data source
• Summary: Coordinape is peer-allocation payroll. Members in a circle gift fixed GIVE balances to each other, then the budget settles off what they received. The later Social Oracle turn is useful, but it is still downstream of the real control surface: membership, epoch design, and payout rules.
• What it does:
  • Organizes contributors into “Circles” that run repeated gifting rounds called Epochs
  • Gives each member a fixed amount of GIVE to allocate to teammates rather than to themselves
  • Converts received GIVE into a pro-rata share of a circle budget when the epoch ends
  • Uses configurable circle rules around participation, visibility, and growth, with a mix of admin control and internal governance
  • Documents an onchain protocol design with badge-gated circle access, vouch-based membership expansion, offchain GIVE movement, and GET redemption against epoch budgets
  • Extended the original circle mechanism into the Social Oracle, where GIVE flows become onchain attestation data on Base that others can query and build on
• Key claims:
  • The official docs describe Coordinape as a way for communities to manage grants, salaries, and projects by letting contributors reward the value they see created, which is the clearest statement that the system is about peer-allocation rather than manager- or token-holder-directed compensation
  • The documentation README says the core unit is the Circle, and that circles can choose their own participation rules and governance toggles, which means practical authority sits in circle configuration and membership control before any payout happens
  • The “How It Works” docs make the core mechanism explicit: each member gets a fixed GIVE balance each epoch, can only send it to others, and the final payout is derived from GIVE received rather than self-reporting or committee scoring
  • The protocol spec is analytically useful because it shows where decentralization stops: gift circles are initially admin-created, budget setting is out of scope, GIVE movement happens offchain during the epoch, and final settlement depends on synchronization or merkle-style publication choices
  • The protocol spec’s badge-and-vouch design matters because access control is not a side detail; it decides who can join a circle, who can receive GIVE, and who can shape the peer-allocation graph in the first place
  • The later Social Oracle materials show that Coordinape’s mechanism escaped the payroll context: GIVE flows are reused as EAS attestations on Base, turning internal peer recognition into a portable onchain trust dataset
  • The CO-token utility docs further show that the reputation layer is not neutral; token holdings can increase GIVE emission rates and caps, which means the system can tilt from pure peer recognition toward token-weighted influence over reputation production
• Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official docs, the official site archive, the protocol repository, and the Social Oracle / CO-token utility docs; see ../whitepapers/coordinape-primary-sources-2026-05-09.md.
• Sources:
  • https://coordinape.com/
  • https://docs.coordinape.com/
  • https://raw.githubusercontent.com/coordinape/docs/master/README.md
  • https://raw.githubusercontent.com/coordinape/docs/master/info/documentation/README.md
  • https://github.com/coordinape/coordinape-protocol
  • https://raw.githubusercontent.com/coordinape/coordinape-protocol/master/README.md
  • https://about.coordinape.com/codao/social-oracle
  • https://raw.githubusercontent.com/coordinape/docs/master/info/co-token-utility.md

Internal linkages

• Closest contribution-legibility sibling: sourcecred

• Best upward reads for treasury-routing and constitutional context: allo-protocol and commons-stack

• Last reviewed: 2026-06-04 UTC