Record that you referred a launch
Attach the authenticated account to a launch as its referrer (§6.1 loop 4). **The referrer is always the caller.** The body carries a launch, never a referrer, so there is no request this route accepts that records a referral against another account. The referral is **idempotent on `(referrer, launch)`**: recording the same pair again updates the existing row rather than adding a second one, because a double-counted referral is a referrer who would be paid twice for one thing. **The share and period recorded are the ones configured right now**, and both are `0` when the deployment has not set them — which is the default. That is honest rather than a loss: the fact this route exists to capture is *who referred which launch*, and that does not change when the economics are decided. Setting the share later does not require referrers to re-attach themselves. `paidFromTreasury` is always `false`: a referral is paid from the rail, never from treasury up front. This route records nothing about money. It is not a payout endpoint and it does not move credits.
Attach the authenticated account to a launch as its referrer (§6.1 loop 4). The referrer is always the caller. The body carries a launch, never a referrer, so there is no request this route accepts that records a referral against another account. The referral is idempotent on (referrer, launch): recording the same pair again updates the existing row rather than adding a second one, because a double-counted referral is a referrer who would be paid twice for one thing. The share and period recorded are the ones configured right now, and both are 0 when the deployment has not set them — which is the default. That is honest rather than a loss: the fact this route exists to capture is who referred which launch, and that does not change when the economics are decided. Setting the share later does not require referrers to re-attach themselves. paidFromTreasury is always false: a referral is paid from the rail, never from treasury up front. This route records nothing about money. It is not a payout endpoint and it does not move credits.
Authorization
bearerAuth A bearer token. The Account routes accept a Privy access token; the MCP transport accepts an sk- API key issued by POST /account/api-keys.
In: header
Request Body
application/json
The launch being referred, and optionally its chain and token.
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/growth/referrals" \ -H "Content-Type: application/json" \ -d '{ "launchId": "string" }'{ "referral": { "id": "string", "referrerId": "string", "launchId": "string", "chain": "ethereum", "token": "string", "shareBps": 0, "periodSeconds": 0, "paidFromTreasury": false, "createdAt": "string" }}Your referral accrual GET
Every launch the authenticated account has referred, and whether the referral-on-rails loop is currently configured to pay (§6.1 loop 4). **Owner-scoped.** The referrer is the bearer; there is no parameter that names another account, so this route cannot be asked for someone else's accrual. **There is no money field, and that is deliberate.** The plan fixes neither the share nor the period, so a response carrying an `earned` amount would be putting a guessed constant into a fee split. What is here is a count, a list, and `accruing` — a boolean about this deployment's configuration, not a claim that money has been earned or will be paid. `accruing: false` with a `referredCount` above zero is a normal, honest state: the referrals are recorded and paying nothing. Reading it is how a referrer knows the loop is not live for this deployment. `paidFromTreasury` is always `false`: paid from the rail, never from treasury up front.
The referral-on-rails loop's status GET
The configuration state of the referral-on-rails loop (§6.1 loop 4): whether it is switched on, the share and period it would pay, and — when it cannot run — exactly which piece is missing. **No bearer token is required.** These are deployment facts, not user data. The loop is **off by default** and the share and period are **both 0** by default, because the plan fixes neither a share nor a period. A non-null `unavailableReason` is the normal answer, not an error: it is the honest report of a loop whose economics have not been decided. `paidFromTreasury` is always `false`. The plan requires a referral to be paid from the rail and never from treasury up front, and the field is the literal `false` so the document carries that invariant rather than leaving it to prose. There is deliberately no `POST` here that records a referrer or pays one. Putting a guessed share into a live fee split is the thing §5.2 does not decide, so this module publishes the configuration the real loop will read and stops there.