Sponsored Features and Feature Funding

Draft 0.1 — 2 August 2026
This protocol is designed for customer-funded product development, not for selling equity, debt, profit participation, or tokenized investment rights. Any arrangement offering financial return requires separate legal analysis.

Objective

ANUKA should allow users to vote with more than a click.

A customer can express real demand by committing money toward evaluation or delivery of a feature. The product receives stronger market validation and a development budget. Contributors receive a funded opportunity. The network records what was requested, promised, delivered, refunded, and learned.

The model must remain understandable:

Fund a product outcome under declared terms—not a vague promise, hidden investment, or unlimited roadmap obligation.

Funding modes

1. Interest signal

A participant votes or follows without payment.

This is demand evidence but not committed revenue.

2. Conditional pledge

A participant authorizes or commits an amount that is charged only when declared activation conditions occur, where the payment provider and applicable payment method support that flow.

The interface must explain authorization expiry and the possibility that a later charge can fail.

3. Refundable sponsorship payment

The sponsor pays now under explicit conditions for refund, cancellation, and delivery.

The product or platform must identify the merchant, refund controller, fees, and timing.

4. Pre-order

The sponsor purchases future access, usage credits, a license, service, or another defined deliverable.

The product must state:

what is being purchased;
expected availability;
material dependencies;
refund policy;
whether the purchase is transferable;
what happens if scope changes.

5. Non-refundable sponsorship

The sponsor funds exploration or development without guaranteed delivery.

This is appropriate only when the sponsor knowingly receives a defined non-delivery benefit, such as participation, research access, recognition, or a report, and the terms are not misleading.

6. Enterprise development commitment

A company funds a feature through a negotiated commercial agreement, potentially with milestones, support, service levels, confidentiality, or limited exclusivity.

7. Matching pool

The product, network, investor, or partner matches qualifying sponsor commitments under published rules.

Prohibited ambiguity

The interface MUST NOT use one button labeled Invest for ordinary feature sponsorship.

Preferred labels:

Fund this feature;
Sponsor evaluation;
Pre-order access;
Commit budget;
Join the matching pool;
Pay for delivery milestone.

Words such as invest, shares, equity, yield, profit, return, and ownership must be used only when the corresponding legal instrument and compliance program actually exist.

Required campaign fields

Every sponsored feature campaign MUST state:

product and merchant;
campaign owner;
problem and intended users;
proposed outcome;
included and excluded scope;
current stage;
funding mode;
target amount and currency;
minimum activation threshold;
maximum amount, if any;
platform and payment fees;
what sponsors receive;
expected schedule or decision dates;
delivery dependencies;
acceptance criteria;
cancellation conditions;
refund rules;
treatment of unused funds;
IP ownership;
privacy and public attribution;
communication cadence;
dispute process;
explicit non-equity and non-return statement where applicable.

Campaign stages

DRAFT
→ VALIDATING
→ FUNDING_OPEN
→ THRESHOLD_REACHED
→ OWNER_ACCEPTANCE
→ FUNDED
→ OPPORTUNITY_PUBLISHED
→ IMPLEMENTING
→ TESTING
→ RELEASED
→ OUTCOME_REVIEW
→ COMPLETED | PARTIALLY_COMPLETED | CANCELED | REFUNDING | DISPUTED

Reaching a money threshold MUST NOT automatically deploy a feature. The owner still applies safety, legal, architecture, and strategic review under the published terms.

Threshold logic

A threshold may cover:

product discovery;
design;
implementation;
review and testing;
infrastructure;
support and maintenance;
platform and payment fees;
contingency;
rollback;
tax.

Campaigns should not present the developer estimate as the entire economic cost when other material costs exist.

Each sponsor record SHOULD include:

sponsor identity or permitted pseudonym;
amount;
payment state;
selected benefit;
refund eligibility;
attribution preference;
communication preference;
consent for public display;
organization, if applicable.

Sponsor amounts must not be converted into governance power unless the campaign explicitly and lawfully defines that right.

What sponsors receive

Possible benefits include:

future product access;
usage credits;
discounted subscription period;
early-access cohort;
design-partner status;
named or anonymous recognition;
testing participation;
implementation report;
priority onboarding;
defined enterprise deliverable;
community credential.

A sponsor does not automatically receive:

equity;
product ownership;
copyright;
veto rights;
permanent roadmap control;
profit share;
guaranteed financial return;
guaranteed launch date.

Feature design authority

Sponsors fund the outcome and declared benefit, not every implementation detail.

The campaign should distinguish:

sponsor-requested need;
product-owner decision;
contributor implementation freedom;
non-negotiable safety and architecture constraints;
acceptance authority.

Large sponsors must not quietly capture a public product roadmap through hidden side agreements.

Funding and payment architecture

ANUKA SHOULD use a regulated payment provider such as Stripe Connect for payment collection and connected-account payouts.

Possible Connect models include:

direct charges where the resident product is merchant of record;
destination charges where the platform collects and transfers to one connected account;
separate charges and transfers where a payment must be split among multiple connected accounts.

The selected charge type changes:

merchant-of-record responsibility;
disputes and refunds;
negative-balance liability;
statement descriptors;
tax and accounting responsibilities;
payout timing.

The product must document the selected model per campaign type.

No casual `escrow` claim

ANUKA MUST NOT market its internal ledger or delayed transfer as licensed escrow.

A payment may be:

collected and held in the platform’s payment-provider balance;
allocated internally;
transferred after conditions;
refunded under campaign terms.

Those mechanics can create regulatory and contractual obligations. FinCEN has treated some platforms that accept, hold, and later release customer funds as money transmitters based on their facts.

Use terms such as:

pending allocation;
sponsor funds received;
transfer scheduled after milestone;
refundable campaign balance.

Use escrow only through an appropriate provider and reviewed legal structure.

Ledger separation

The platform ledger MUST separate:

gross sponsor payment;
payment-provider fee;
tax;
refundable principal;
product allocation;
contributor allocation;
reviewer allocation;
ANUKA platform fee;
reserve;
refunded amount;
transferred amount;
disputed amount.

Displayed balance must state whether it is:

informational ledger balance;
available spending credit;
pending payment-provider balance;
refundable customer funds;
earned contributor amount;
withdrawable connected-account balance.

Release of funds

Possible release triggers:

campaign owner acceptance;
milestone acceptance;
qualified review;
production release;
elapsed refund window;
measured outcome;
manual resolution.

No single default fits every campaign.

The trigger must be known before payment.

Refund policy

Campaigns MUST define refund events.

Possible events:

threshold not reached by deadline;
owner declines activation;
product cancels before implementation;
material scope change rejected by sponsor;
missed final delivery window;
duplicate payment;
fraud;
platform or legal prohibition;
contributor failure;
partial delivery;
sponsor withdrawal within declared period.

Refund policy should state:

full or partial amount;
treatment of payment fees;
processing time;
currency conversion treatment;
whether consumed benefits reduce the refund;
dispute route.

Partial completion

If only part of the feature is delivered, the product may:

deliver a reduced benefit with sponsor consent;
refund unused allocation;
issue product credits;
extend the campaign;
propose a replacement scope;
close with a transparent failure report.

Silence is not an acceptable resolution.

Feature implementation marketplace

When a campaign activates, it may generate:

discovery bounty;
architecture review;
design opportunity;
implementation milestones;
testing and qualification bounties;
documentation work;
rollout monitoring;
outcome review.

The sponsor campaign and contributor assignments are separate objects with linked budgets.

Voting and money

ANUKA should show at least three different demand measures:

number of interested participants;
number of paying sponsors;
committed amount.

A large payment from one company and small payments from many users are different market signals. The interface should not flatten them into one popularity rank.

Fraud and manipulation

Controls may include:

payment verification;
rate limits;
duplicate-account detection;
connected-account onboarding;
sanctions screening;
campaign-owner verification;
public revision history;
sponsor concentration display;
related-party disclosure;
refund abuse detection;
reviewer conflict checks.

The network must distinguish legitimate anonymous sponsorship from hidden self-funding used to manufacture demand.

Public proof of demand

A campaign may publish:

count of sponsors;
funded amount or band;
funding velocity;
campaign status;
public comments;
sponsor concentration band;
delivery progress;
verified release;
refund completion;
observed outcome.

Founder control and sponsor consent apply to attribution and sensitive amounts.

Investment and securities boundary

The MVP MUST NOT promise sponsors:

a financial return;
appreciation;
dividends;
profit share;
revenue share;
repayment with interest;
equity;
transferable claims whose value depends on product success.

If ANUKA later enables those rights, the feature moves into a separately regulated capital-formation product.

Putting an economic right on a blockchain does not change its substance. The SEC states that tokenized securities remain securities.

Consumer-protection boundary

Objective statements about delivery, validation, quality, demand, and results require a reasonable factual basis before publication.

Campaign pages must not:

fabricate sponsor counts;
hide material fees;
imply guaranteed delivery when none exists;
represent simulation as actual performance;
call unverified demand verified;
omit known material dependencies;
silently change refund terms.

Taxes

The campaign must determine:

who is seller or merchant;
whether the payment is a sale, deposit, sponsorship, service fee, or other category;
sales-tax or marketplace-facilitator responsibilities;
income recognition;
contractor reporting;
cross-border tax implications.

Stripe Tax can support calculation and reporting, but the platform or connected account must determine who has the legal tax obligation.

MVP acceptance criteria

interest, pledge, refundable sponsorship, and pre-order are separate modes;
owner and merchant are displayed;
target and activation conditions are explicit;
sponsors choose benefits and attribution;
non-investment terms are prominent;
internal ledger separates allocations;
refunds are automated where rules are objective;
campaign revisions are versioned;
activated campaigns generate typed contributor opportunities;
sponsor concentration is visible;
unspent funds have a declared policy;
no use of escrow without reviewed basis;
no financial-return rights in MVP.

Sources

Verification record

Sources opened and checked: 2 August 2026
Protocol status: Founding draft
Payments and money-transmission review required: Yes
Consumer terms and refund review required: Yes
Securities review required before any financial-return feature: Yes