DOCUMENTATION

How Streamline handles money

Every coin is a Meteora dynamic bonding curve with a fixed tax the creator sets at launch. This page is the whole mechanism: what the curve does, what the tax is, and what happens to a fee between a trade and a real person receiving something.

Overview

A Streamline coin has a beneficiary written into it at launch. Traders buy and sell on a bonding curve. A fixed percentage of every trade is taken as a tax, split three ways, and the largest share leaves the chain entirely and arrives as gifted subs, a donation, or a sponsorship.

Nothing about that is automatic magic. A payout involves us converting SOL to dollars and spending it somewhere. The rest of this page says exactly how, per destination, including what each destination keeps.

The curve

Every coin uses the same curve, so a trader learns it once and it holds everywhere on the platform.

CurveMeteora Dynamic Bonding Curve
Quote assetSOL
Total supply1,000,000,000
Graduates at85 SOL of net buys
Supply seeded at graduation20%
Migrates toMeteora DAMM v2
LP at migrationPermanently locked
Fee after migrationUnchanged

Once net buys reach 85 SOL the pool migrates and liquidity is locked permanently. Fees do not stop at graduation. Locked LP keeps earning, and that keeps flowing to the same vault the beneficiary is paid from.

The creator tax

The creator picks a tax between 1% and 3% when they launch. It applies to buys and sells alike and it never changes, from the first trade to long after graduation.

A creator can optionally buy some of their own coin in the same transaction as the launch. It cannot be front‑run, because the pool does not exist until that transaction lands, and it pays the same tax as any other trade. A dev buy is therefore the first money toward the beneficiary.

The rate is set on the config key rather than the pool, so coins sharing a rate share a config. That is an implementation detail with one visible consequence: the first coin at a given rate costs slightly more to launch than the ones after it.

Where every fee goes

Meteora takes 20% of every trading fee before anything reaches us. That is a cost of using the curve and nothing we can configure changes it. What is left splits three ways.

Meteora protocol fee20% of the tax
Beneficiary70% of the rest — 56% of the tax
Creator20% of the rest — 16% of the tax
$STREAM buyback10% of the rest — 8% of the tax

On chain there is only one account. The whole tax accrues to a single vault per coin, which the platform claims. All three shares above are then paid out of that vault and recorded against the coin that produced it.

Worked example, on $1,000 of volume through a coin taxed at 2%:

Volume traded$1,000
Tax paid by traders$20.00
Meteora takes$4.00
Into the vault$16.00
→ earmarked for the beneficiary$11.20
→ owed to the creator$3.20
→ earmarked for buyback$1.60

Volume rather than a single buy, because a fee is a percentage and one trade is too small to show anything once it is split four ways. Buys and sells both count.

Handling by category

The beneficiary share leaves the chain differently depending on what the coin points at. Each rail has its own conversion path, its own release rule, and its own cut taken by the destination before the recipient sees anything.

X profile

RECIPIENT MUST CLAIMno destination cut
CAPITAL FLOWautomaticby hand today · 1 of 7
  1. Fees accrueIn the pool vault, as SOL
  2. ClaimPartner claim, on chain
  3. SweepInto the payout wallet
  4. EscrowHeld as SOL
  5. They sign inWith X, on our claim page
  6. SendTo their xMoney balance
  7. AccountNo platform cut

HOW IT RUNS TODAY

Nothing moves until the account holder signs in with X and proves the handle. Once they do, a person sends the payment. Unclaimed after the window, it goes to holders automatically.

ONCE IT IS AUTOMATED

X login already handles the proof. The send becomes an xMoney API call once that integration exists, at which point this rail is fully hands-off.

SETTLEMENT
Paid to the account's xMoney balance
CONVERSION
SOL held as SOL until claimed, then converted at claim time
RELEASE RULE
Held until the account signs in with X. Unclaimed after 30 days, it goes to holders
MINIMUM PAYOUT
$10 — below this the vault keeps accruing
RECEIPT
The claim transaction, on chain

Twitch

NO SIGNUP NEEDEDTwitch keeps 50%
CAPITAL FLOWautomaticby hand today · 4 of 8
  1. Fees accrueIn the pool vault, as SOL
  2. ClaimPartner claim, on chain
  3. SweepInto the payout wallet
  4. OfframpSOL to USD
  5. Fund cardVirtual card, loaded
  6. Wait for livePoll the channel
  7. Gift subsBought at checkout
  8. StreamerTwitch keeps half

HOW IT RUNS TODAY

A person converts the SOL, loads a virtual card, watches for the channel to go live, then buys a sub bomb at checkout and saves the clip. Roughly ten minutes of work per payout.

ONCE IT IS AUTOMATED

The offramp and card funding become API calls, and live status comes from the Twitch Helix API on a poll. Buying the subs is the last manual step, because Twitch has no purchase API, so it stays a scripted browser session for a while yet.

SETTLEMENT
Gifted subs on the channel
CONVERSION
SOL to USD, then a funded virtual card used at Twitch checkout
RELEASE RULE
Held until the channel is live, then spent in one bomb so the alert lands in front of an audience
MINIMUM PAYOUT
$50 — below this the vault keeps accruing
RECEIPT
The sub-bomb alert on stream and the channel's own gifter list

YouTube

NO SIGNUP NEEDEDYouTube keeps 30%
CAPITAL FLOWautomaticby hand today · 4 of 8
  1. Fees accrueIn the pool vault, as SOL
  2. ClaimPartner claim, on chain
  3. SweepInto the payout wallet
  4. OfframpSOL to USD
  5. Fund cardVirtual card, loaded
  6. Wait for activityLive or posted recently
  7. Gift membershipsBought on the channel
  8. ChannelYouTube keeps 30%

HOW IT RUNS TODAY

Same card, bought as gifted memberships instead of subs. We wait for the channel to be streaming or to have posted within two days, so the gift is seen rather than buried.

ONCE IT IS AUTOMATED

The YouTube Data API reports live status and recent uploads, so the wait becomes a poll. Purchase stays manual for the same reason as Twitch.

SETTLEMENT
Gifted memberships on the channel
CONVERSION
SOL to USD, then a funded virtual card used at YouTube checkout
RELEASE RULE
Held until the channel is streaming or has posted within 48 hours, so the gift is seen
MINIMUM PAYOUT
$50 — below this the vault keeps accruing
RECEIPT
The membership gift notice on the channel

Kick

NO SIGNUP NEEDEDKick keeps 5%
CAPITAL FLOWautomaticby hand today · 4 of 8
  1. Fees accrueIn the pool vault, as SOL
  2. ClaimPartner claim, on chain
  3. SweepInto the payout wallet
  4. OfframpSOL to USD
  5. Fund cardVirtual card, loaded
  6. Wait for livePoll the channel
  7. Gift subsBought at checkout
  8. StreamerKick keeps 5%

HOW IT RUNS TODAY

Identical to the Twitch flow, and the same person does both in one sitting. The difference is how much lands: on Kick nearly the whole gift reaches the streamer.

ONCE IT IS AUTOMATED

Same as Twitch. Kick's public API covers live status, so only the checkout stays manual.

SETTLEMENT
Gifted subs on the channel
CONVERSION
SOL to USD, then a funded virtual card used at Kick checkout
RELEASE RULE
Held until the channel is live, then spent in one bomb
MINIMUM PAYOUT
$25 — below this the vault keeps accruing
RECEIPT
The sub-bomb alert on stream and the channel's own gifter list

GoFundMe

NO SIGNUP NEEDEDGoFundMe keeps 3%
CAPITAL FLOWautomaticby hand today · 3 of 7
  1. Fees accrueIn the pool vault, as SOL
  2. ClaimPartner claim, on chain
  3. SweepInto the payout wallet
  4. OfframpSOL to USD
  5. Check campaignStill accepting
  6. DonateOn the campaign page
  7. CampaignAbout 3% processing

HOW IT RUNS TODAY

A person donates on the campaign page under the same team name every time, which is what makes a payout verifiable in one click by anyone.

ONCE IT IS AUTOMATED

Least automatable of the rails, because GoFundMe has no donation API. The realistic end state is a scripted checkout with a human approving each one.

SETTLEMENT
A donation to the campaign
CONVERSION
SOL to USD, then card payment on the campaign page
RELEASE RULE
Sent on the next batch while the campaign is still accepting donations
MINIMUM PAYOUT
$10 — below this the vault keeps accruing
RECEIPT
The donation on the campaign page, under the same team name every time

GitHub

RECIPIENT MUST CLAIMno destination cut
CAPITAL FLOWautomaticby hand today · 3 of 7
  1. Fees accrueIn the pool vault, as SOL
  2. ClaimPartner claim, on chain
  3. SweepInto the payout wallet
  4. OfframpSOL to USD
  5. Check SponsorsProfile must exist
  6. SponsorOne-off payment
  7. MaintainerGitHub takes nothing

HOW IT RUNS TODAY

We check the repo has a Sponsors profile, then make a one-off sponsorship from the team account. It shows publicly on their sponsors page, which is the receipt.

ONCE IT IS AUTOMATED

The GitHub API reports whether Sponsors is enabled, so the check automates cleanly. Payment stays manual because Sponsors has no programmatic checkout.

SETTLEMENT
A one-off GitHub Sponsors payment to the maintainer
CONVERSION
SOL to USD, then card payment through Sponsors
RELEASE RULE
Held until the maintainer has a Sponsors profile. Unclaimed after 30 days, it goes to holders
MINIMUM PAYOUT
$25 — below this the vault keeps accruing
RECEIPT
The sponsor entry on the maintainer's public Sponsors page

Charity

NO SIGNUP NEEDEDno destination cut
CAPITAL FLOWautomaticby hand today · 2 of 7
  1. Fees accrueIn the pool vault, as SOL
  2. ClaimPartner claim, on chain
  3. SweepInto the payout wallet
  4. OfframpSOL to USD
  5. Batch weeklyACH has fixed overhead
  6. Bank transferStraight to the nonprofit
  7. NonprofitNothing lost to fees

HOW IT RUNS TODAY

Batched once a week and sent by bank transfer rather than card, so none of it is lost to processing. The acknowledgement or tax receipt goes on the coin page.

ONCE IT IS AUTOMATED

The most automatable rail. ACH is a normal payments API, so once the offramp lands this runs end to end with no hands on it.

SETTLEMENT
A bank transfer to the nonprofit
CONVERSION
SOL to USD, then ACH, so nothing is lost to card fees
RELEASE RULE
Batched weekly, because ACH has fixed overhead per transfer
MINIMUM PAYOUT
$100 — below this the vault keeps accruing
RECEIPT
The acknowledgement or tax receipt, published on the coin page

Claiming and funding

Between a fee and a person receiving something there are five steps.

  1. 01Fees accrue in the pool's vault, in SOL, as people trade.
  2. 02The platform claims the partner share out of the vault on chain.
  3. 03Claimed SOL is converted to dollars and loaded onto a virtual card, or sent by bank transfer where the destination takes one.
  4. 04The payout is spent at the destination, held first where the release rule says to hold.
  5. 05The receipt is posted against the coin, linking both the on-chain claim and the third-party evidence.

Once a payout is releasable it goes out within 24 hours. Where a rail needs the recipient to claim, the vault waits 30 days. After that the money goes to holders instead, and no one, including us, can send it anywhere else.

Receipts

Every payout carries two links: the on-chain claim that funded it, and evidence hosted by someone who is not us. A sub bomb shows in the channel gifter list. A GoFundMe donation shows on the campaign page. A Sponsors payment shows on the maintainer's page.

What we do not do

  • We do not change a coin's beneficiary after launch. Nobody can, including us.
  • We do not change a coin's tax after launch.
  • We do not take unclaimed vaults. They go to holders after the claim window.
  • We do not imply that a beneficiary endorses a coin. Anyone can launch for anyone, which is the point and also the risk.
  • We do hold the creator's share, so it is an obligation we owe rather than something they can take without us. It is earmarked on every claim and shown against their coin.