Skip to content

Building the FOAF protocol stack on Radix

Status

The FOAF token has been live on Ethereum since December 2018. Total supply 25 million, indivisible, fixed, never distributed. The Foundation holds the entire allocation and will distribute it through the model documented in tokenomics.

The first application on the protocol, GrowOperative, is currently running on Rails and MySQL, with a soft launch underway in Crawford Bay, BC. The on-chain protocol stack becomes load-bearing in Phase 3 of the roadmap, when network fees activate, RHEO consumption becomes the metering layer for protocol operations, and DAO governance takes effect.

This work is the on-chain protocol stack itself: staking, RHEO, governance, treasury. Separate from the Hyperlane bridge work (covered in Bringing FOAF to Radix) and the peer-to-peer credit graph layer (covered in The peer-to-peer architecture).

The objective

Design and ship a coherent set of Scrypto components.

Staking. vFOAF and rFOAF as soulbound resources representing locked FOAF, with withdrawal rules baked into the resource definition. vFOAF is liquid-locked (stake any time, unstake any time, 1:1). rFOAF is time-locked from 6 months to 2 years with a multiplier curve.

RHEO accrual. Non-transferable, soulbound utility credit generated by stake amount and time. Lazy accrual: RHEO does not materialize as a held balance between accrual and consumption. The consumption path burns RHEO at the moment of use through a trust-graph chain that records bilateral credit obligations on the consumer's side.

Governance. Threshold-tiered voting where qualifying tier is determined by rFOAF stake and lock duration, but vote weight within a tier is one-per-account. Each tier exposes specific proposal types with specific quorum and execution rules.

Treasury. A DAO-controlled component holding the foundation's reserve, with proposal-gated disbursement.

Final spec on each of these is partially set and partially being refined. A senior Scrypto contributor would help complete the design as well as implement it.

What needs to be built

The FOAF resource itself is created in the bridge work. Assume it exists when this work starts.

A pair of staking components for vFOAF and rFOAF. Lock FOAF, mint a non-transferable receipt resource that represents the staked position, and track the timestamp and lock parameters needed for RHEO accrual and unlock eligibility. The receipt resources must be soulbound by construction, not by convention. Withdrawal logic must enforce timelocks at the resource level so no off-chain trust is required.

An RHEO accrual model that lives in the staking component, not as a separate token contract. RHEO does not need to be a materialized fungible resource between accrual and consumption. The component computes accrued balance on demand from stake × elapsed × multiplier, and at consumption time mints just enough RHEO to cover the operation, then burns it inside the same manifest that performed the consumption. The user-visible RHEO balance is a view function, not stored state. Worth confirming this design choice with an audit reviewer before committing. The alternative (always-materialized RHEO) is simpler but more expensive and loses the structural advantage of the soulbound consumption pattern.

A consumption path that ties RHEO burn to a bilateral credit obligation in the trust graph. The data model for the obligation lives partly in the off-chain protocol layer (the P2P track) and partly here (on-chain anchor record). Coordination with the P2P architecture team on the boundary.

A governance system using badges as the authority resource. Each tier corresponds to a badge type. Holding a tier-N badge qualifies an account to vote in tier-N proposals. Badge eligibility derives from rFOAF stake and lock duration. When those change, badges update. Votes are one-per-badge-holder within a tier, not stake-weighted within a tier.

A proposal component that handles submission, discussion period, voting period, quorum check, and execution. Execution should call into the relevant component (parameter change, treasury disbursement) directly rather than requiring a multisig step.

A treasury component that holds the foundation's FOAF reserve and disburses only on successful proposal execution.

What is not in scope

The following are adjacent but separate:

The boundary between this work and the P2P track is "what's on chain vs. what's bilateral private." This work owns everything on chain. The P2P track owns everything off chain. Anchoring is the seam.

Why this is interesting work

Honest reasons.

The design is not a port of an Ethereum staking pattern with Radix syntax. It's intentionally exploiting Radix primitives that don't exist on Ethereum. RHEO never has to materialize between accrual and consumption. The burn happens in the same manifest as the mint. Governance authority is itself a resource, not a permission flag. Cross-component atomic composition replaces the multi-transaction patterns Ethereum projects work around with retries and reconciliation.

The mission is community mutual credit, not speculative DeFi. The audience for what this stack secures is households trading surplus food and small cooperatives with bounded membership. Whether that sounds boring or refreshing depends on the developer.

The design is partly open. A contributor with a strong opinion on, for example, how lazy accrual should compose with proposal voting, has room to shape the answer rather than execute someone else's spec.

The Radix ecosystem has few reference cases for asset-oriented governance and soulbound utility tokens designed coherently as a system. Whoever does this well first will get cited.

What is offered

Compensation is a FOAF allocation with vesting, drawn from the 16% team-and-advisors pool. Size is negotiated case by case based on scope and milestones. The default structure is a 6-month cliff with milestone-based unlocks across 12 to 24 months.

Tokens are the primary compensation. A cash retainer can be part of the package for engagements that need one, but only once the seed round closes. Better to say that up front than have the timing be a surprise later.

Public attribution in the project's documentation and any released materials.

A working relationship with the Foundation founder. Decisions get made in the same conversation, not three weeks later.

Continuing involvement is welcome but not required. A clean engagement that ends when this stack ships is fine too.

What is expected

Demonstrated experience writing Scrypto components. At minimum a published Babylon project. Comfort with the resource model, badge-based authority, and atomic composition.

Interest in the design questions, not just the implementation. Someone who treats "we use lazy accrual because it composes cleanly with consumption" as a meaningful sentence rather than a buzzword.

Willingness to document what gets built, in enough detail that another developer could read it later and understand why the decisions were made.

Communication on a reasonable cadence. Async is fine; weeks of silence is not.

How to start a conversation

Through the Radix community channels where this work is being discussed, or directly via the contact link on the Foundation site. The first conversation is just a conversation. There is no commitment expected from either side until both sides have a clear sense of what the work is and what the engagement looks like.

No application form. No interview process. Show up, talk, see if it fits.