Funding Groups
Funding groups are approved charitable causes that can receive revenue splits from smart product mints.
A funding group is a pre-approved charitable cause or organization registered with the protocol. Products can allocate a percentage of mint revenue to one via a FUNDING_GROUP contribution.
Schema
interface FundingGroup {
id: number;
name: string;
description: string | null;
stxAddress: string | null;
status: FundingGroupStatus;
website: string | null;
createdAt: string;
}
type FundingGroupStatus =
| "PENDING" | "APPROVED" | "VERIFIED" | "REJECTED" | "SUSPENDED";Approval workflow
- APPROVEDadmin approves
- REJECTEDadmin rejects
- VERIFIEDon-chain proof
- SUSPENDEDadmin suspends
- SUSPENDEDadmin suspends
- APPROVEDrestore
- VERIFIEDrestore
- Group applies (status:
PENDING) - Admin approves (
APPROVED) or rejects (REJECTED- terminal) - On-chain proof upgrades to
VERIFIED - Admins can
SUSPENDand restore toAPPROVED/VERIFIED
Only APPROVED or VERIFIED groups can be referenced in a contribution.
Using a funding group
Allocations are fixed when the product is created, in the contributions input, and frozen on deploy. There is no add-after-deploy - once the contract is live the splits are immutable.
await rtClient.smartProducts.createPage({
// ...page fields
contributions: {
fundingGroups: [
{ id: 42, percentage: 5 }, // 5% of every mint to approved group #42
],
},
});You supply only the group id and percentage. The server resolves the group's payout address and derives the recipient, so a creator can never point a FUNDING_GROUP cut at an arbitrary address.
On-chain settlement
The group's stxAddress is written into the unified creator-info map at contract deploy time, alongside the creator, template-artist, sticker-artist, and collaborator entries. distribute-fees pays every entry on each mint, and the Chainhook position-verifier reads them back by frozen position. The FUNDING_GROUP vs creator distinction lives off-chain in ProductContribution.role - on chain it is just another creator-N slot, so no special template handling is required.
API endpoints
| Method | Path | Description |
|---|---|---|
GET | /api/funding-groups | List |
GET | /api/funding-groups/:id | Get one |
POST | /api/funding-groups | Register (Admin) |
PUT | /api/funding-groups/:id | Update, including status transitions (Admin) |
DELETE | /api/funding-groups/:id | Delete (Admin) |
Status transitions run through the PUT update and are guarded service-side (PENDING -> APPROVED|REJECTED, APPROVED -> VERIFIED|SUSPENDED, and so on); a backwards transition is rejected 409.
See FundingGroupStatus for the full transition table.