Skip to main content
Source: Full executable TypeScript in contract/src/examples/00-platform-enlistment/. This page summarizes the flow — read the source for complete per-step code.

The Story

NovaPay is a digital marketplace that helps independent sellers accept payments online. They want to integrate Oak Protocol to offer their merchants on-chain payment processing and crowdfunding capabilities. Before any campaign can be created or treasury deployed on their platform, NovaPay must first be enlisted as a platform on the protocol. Platform enlistment is a coordinated process between two roles:
  • The Protocol Admin (the Oak Network team) — who governs the GlobalParams contract and must approve every new platform joining the protocol
  • The Platform Admin (NovaPay’s operations wallet) — who will manage the platform’s day-to-day configuration once enlisted, such as treasury registration, fee settings, and payment operations
There is no self-service signup. NovaPay contacts the Oak support team, provides their admin wallet address, and agrees on a fee structure. The Protocol Admin then records the enlistment on-chain in a single transaction. Once enlisted, NovaPay registers the treasury implementation contracts they want to use. A platform can register as many or as few treasury models as they need — even a single model is enough to get started. Each registration enters a “pending” state and must be explicitly approved by the Protocol Admin before it can be used to deploy treasuries.

Platform Hash

Every platform on Oak Protocol is identified by a bytes32 value called the platform hash. It is the keccak256 hash of the platform name and remains fixed for the lifetime of the platform.

Implementation ID Layout

Each platform maintains its own mapping of implementation ID to treasury contract inside TreasuryFactory:

Role Reference

Steps

Step 1: Enlist the Platform

The Protocol Admin calls enlistPlatform on GlobalParams. This single transaction sets the platform hash, admin address, fee percent, and adapter. Any other caller reverts with GlobalParamsUnauthorizedError.

Step 2: Verify the Enlistment

After the Protocol Admin enlists NovaPay, anyone with a read-only client can verify the on-chain state. No private key is needed — these are pure view calls against GlobalParams.

Step 3: Register a Treasury Implementation

Now that NovaPay is enlisted, the Platform Admin registers the treasury model they want to use. Each model goes into a numbered slot (implementationId) on TreasuryFactory. Registrations are not immediately active — they sit in a pending state until the Protocol Admin approves them.

Step 4: Approve the Implementation

The Protocol Admin explicitly approves the registered implementation. This is a safety gate — the protocol team verifies the implementation contract before allowing the platform to deploy treasuries from it. Each registered slot requires its own approval call.

Step 5: Verify Full Setup

Before going live, NovaPay’s admin runs a final check to confirm every piece of the onboarding is in place: the platform is listed, admin and fee values match agreed terms, and treasury implementations are registered and approved.

Step 6: Optional Configuration

After core onboarding, a platform can configure additional features. These are all optional and independent — skip any you don’t need. Example — register a line item type for “product” (counts toward goal, refundable):

Multi-token currencies

GlobalParams holds currencyToTokens: bootstrapped in initialize(currencies, tokensPerCurrency), then the protocol owner can addTokenToCurrency / removeTokenFromCurrency; anyone can read getTokensForCurrency(currency). When CampaignInfoFactory creates a campaign, it reads the current token list and stores a snapshot on CampaignInfo; treasuries validate every paymentToken / pledgeToken against that cache.