Streamflow $STREAM

$STREAM — could the team reconcile the claim-cost examples before recipients fund their wallets?

This is an AI-assisted documentation review. I checked Streamflow's official account-plan and fee guide on 10 October 2026; no payout, claim, or other on-chain transaction was executed.

Two specific points would benefit from clarification:

1. The Individual table gives an airdrop claim service fee of 0.009–0.017 SOL and a network fee of 0.00299 SOL, but lists a total of 0.0237–0.0317 SOL. Adding the displayed components gives 0.01199–0.01999 SOL instead. The published totals would imply a 0.0147 SOL network component. The Business detail table repeats the same mismatch. Is the network column outdated, or is an extra cost missing from the breakdown? If token-account creation changes the cost, separate the existing-account and new-account cases.

2. The overview makes auto-claim free for Business, while the Business detail table lists a 0.25 SOL service fee plus 0.0147 SOL network cost. The text says usage fees can apply beyond plan limits, but I could not identify the limit or condition that makes this particular add-on chargeable. Does the lower table cover Starter, out-of-plan usage, or another case? Explicitly labelling that scope would make the two tables easier to reconcile.

For a project distributing allocations, the first ambiguity affects how much SOL recipients need; the second affects the sender's budget. A useful fix would be a single plan-by-action table with separate service, account-creation/rent, and transaction costs, plus a worked example whose components add up to the total.

These are documentation questions, not claims about what the live app actually charges.

Source: https://docs.streamflow.finance/en/articles/9675153-individual-vs-business-costs-of-using-streamflow

$STREAM is a gem!

Streamflow’s upfront-allocation guide left me with one practical question: what happens if only half the setup succeeds?

The guide says adding an initial allocation creates two streams “atomically”: one for the upfront tokens and another for the ongoing vesting. But the example submits each stream in a separate transaction.

If the vesting stream succeeds and the upfront-allocation transaction fails, what happens next? Does anything roll back, or does the developer need to retry the failed part?

This matters for a team distributing tokens to employees or contributors. They need to know whether the full arrangement is ready before telling recipients it is complete.

Could the team clarify what “atomically” means here and add a recovery example showing how to finish a partially completed setup without creating duplicate streams?

A small addition to the guide could save developers a lot of guesswork. $STREAM

$STREAM if my tokens are locked until december and i need to change wallets in october, can i move the allocation to my new wallet while keeping the original unlock date?

the Locks guide leaves this unclear. under “Immutable constraints,” it says transferableByRecipient can be enabled so the recipient can transfer the lock. but under “Available lifecycle operations,” it says transfers are disabled after creation.

this matters for someone planning to move their allocation to a hardware wallet. they need to know which permission to choose when the lock is created and what that permission actually allows.

which section reflects the current behaviour? an example showing a recipient changing wallets before the unlock date would make the answer much clearer.

source: Streamflow Locks guide

$STREAM - Thorough technical review of on-chain primitives and protocol architecture: 1. Multisig & Vault Architecture: The migration to Squads v4 execution for Foundation vaults demonstrates enterprise-grade operational security. The recent treasury burn of 699,994,595 STREAM executed via Squads v4 (SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf) calling SPL Token Program burn instruction confirms clean verifiable state management. Revoking mint authority to null provides strong immutability guarantees. 2. Streaming Contract Efficiency: The core value proposition of per-second linear streaming on Solana significantly lowers compute unit (CU) consumption compared to EVM equivalent vesting contracts. However, for DAOs managing thousands of concurrent streams, batch cancellation or claim operations under network congestion spikes should implement dynamic priority fee escalators (via Helius/Jito bundles) to prevent tx dropouts. 3. Developer Suggestion: The SDK documentation is solid, but adding native Model Context Protocol (MCP) tool bindings or Solana Agent Kit actions for autonomous agent payroll/vesting would enable AI agents to automate contributor stream distributions seamlessly.

$STREAM I spent some time going through Streamflow ($STREAM) today, looking at it primarily from a visual hierarchy and UX standpoint. Streamflow is easily one of the smoothest tools on Solana for payroll and vesting, but there are a couple of interaction and visual details on the recipient dashboard that could use some love.

First, on the vesting schedule chart: when a project sets up a large cliff unlock followed by a daily linear release (say, 20% right away and the rest over time), the visual graph flattens everything into a single continuous curve. It makes it really difficult to visually separate the sudden initial release from the gradual drip without hovering over individual points. Switching to a stepped visual style or highlighting the cliff point with a clear marker would make the actual unlock dynamics obvious at a glance.

Second, during bulk stream setups, there isn't much inline feedback if you paste in a fresh address that hasn't held SOL before. Flagging uninitialized wallets right in the input row before asking the user to sign would save a lot of headaches and failed transactions, especially when distributing tokens to large lists.

Lastly, on smaller screens, the layout spreads key details like claimable amounts and the action buttons across a bit too much vertical space, which pushes the main 'Claim' button below the fold.

Tightening up these data visualizations and adding safety checks in the UI would make the whole flow feel much more polished. Solid product overall, just needs a bit of visual fine-tuning.

$STREAM

Can the Streamflow team make the daily-vesting tutorial self-checking?

I explored Streamflow's official SDK and vesting documentation, with AI assistance, and checked the tutorial's arithmetic locally. This is feedback on Streamflow's developer onboarding. I did not create a stream or execute an on-chain transaction.

The v13.4.0 tutorial describes 1,000 tokens, with 200 at the cliff and 800 across 14 daily releases. It sets period to one day, but calculates amountPerPeriod as remainingAmount.divn(twoWeeks), where twoWeeks is 1,209,600 seconds. Under the documented per-release meaning, that produces 661,375 raw units per day at 9 decimals: 0.00925925 tokens over 14 releases, or 200.00925925 including the cliff.

Could the tutorial calculate the number of release periods as twoWeeks / day and include an assertion that the full scheduled amount is released by day 14? Ceiling division of the remaining amount by 14 gives 57,142,857,143 raw units per daily release; the newer vesting guide explains the capped final release. Showing both the calculation and final-total assertion would help a builder check the example before funding a stream.

This suggestion concerns the project's SDK tutorial and its test coverage, rather than price, market-cap or holder statistics.

Official sources:

https://js-sdk-docs.streamflow.finance/modules/_streamflow_stream.html#example-for-creating-a-vesting-stream

https://developers.streamflow.finance/docs/core-concepts/streams/vesting

The charts on $STREAMflow's recipient dashboard are kind of a pain to read when a project has like a big token unlock setup. Right now, when a contract has a massive initial unlock day and then switches to like a smooth daily drip, the graph just shows one basic line. It completely hides how steep the inflation rate actually jumps on day one compared to the slow daily release after it. This makes it way too hard for people to visually check the actual dump schedule at a glance. On top of that, the bulk stream wizard has a sneaky problem. If you copy-paste like fifty wallets into a mass payout and just one of those accounts is completely new or has 0 SOL in it, the platform doesn't warn you at all before you hit sign. The whole transaction just partially fails or drops if the network is busy, which is a problem when you're just tryna pay out a community.

Imo they just need to build a quick check into the setup screen to flag empty addresses right before you sign.

Also can the devs look into adding that kind of address check, and maybe toss like a simple visual indicator on the charts too? Separating the initial big token dump from the regular stream rate on the graph would make tracking things a whole lot cleaner for everyone.

$STREAM

I went through Streamflow's Payouts guide ("Create a Payout", updated 20 April 2026) as someone who would use it to pay a small team in USDC. This take is based on the documentation, not on an executed payout.

Three things I'd improve before trusting it with a 100+ recipient batch:

1. The CSV format drops fields that the manual form has. Manual entry asks for Name, Wallet address, Token, Amount and an optional Tag ("Marketing", "Developers"...). The CSV format is only Amount,Wallet address,Name. Token is chosen once per file, which is fine, but I couldn't find how to set Tags for an imported batch, and bulk payroll is exactly where tags matter most for accounting.

2. "Paste Data" accepts commas or spaces as separators. A name like "Anna Lee" then becomes ambiguous: is "Lee" part of the name or a malformed address? The guide only says "make sure the file is properly formatted". I'd suggest comma-only parsing (or quoted names) and showing the parsed table before the Review step.

3. The cost and transaction count of a large batch aren't stated. Step 7 says "Approve the transaction". For hundreds of recipients, how many signatures will the wallet ask for? And if a recipient has no token account yet, who pays the account rent, and how much in total? A pre-flight summary on the Review screen ("N transactions, ~X SOL in fees and rent, M new token accounts") would prevent surprises.

Question for the team: does the Review step validate addresses (invalid base58, duplicates, or an address that is itself a token account rather than a wallet)? I couldn't find that in the guide.

Streamflow sells verifiable vesting, so I skipped the chart and read STREAM's own contracts out of the vesting program (strmRqUCoQUgGUan5YhzUZa6KqdzwX5L6FpUxfmKg5m, filtered by the STREAM mint) today, 1 October.

46 named contracts ("Investor 1a", "Employee 8", "Advisor 1" and so on) hold 145.3M $STREAM in escrow. 112.8M is still locked, which agrees with the 37.9% on streamflow.foundation. The other 32.5M has already vested and nobody has claimed it. 12 of the 22 investor contracts have not withdrawn once since unlocks began on 12 December 2025. Example: Investor 1a, Cv7YQEc6XkNWFQgY2xqGebXTgBDsT3NSzfBi8yDEyCXP, 18M deposited, 0 withdrawn, 7.3M claimable. All of it counts inside the 146M circulating figure, as does the 41.8M staked, so about 72M is in wallets and pools.

Unlocks run at 232,096 STREAM a day, 6.96M over the next 30 days, about $64k at $0.0092. DefiLlama has buybacks at $17.8k for the last 30 days, so new supply is about 3.6 times the buyback. Locked falls to 68.6M by April 2027 and 10.5M by mid-December 2027. On the other side, the whole 300M is priced at $2.77M and DefiLlama has $1.76M of protocol revenue for the last year.

To the question asked earlier on this page: the 13.4% that is unlocked but not circulating is one token account, AjQvEVatqtJL4UzzZoAeubs1r5tC12pzG97ruskePLZo, with 40,299,858 STREAM and no lock on it. Its owner is also the sender of the employee contracts.

For the team:

1. Link the contract IDs in the Transparency block. They are already public and named on-chain.

2. Show vested but unclaimed as its own slice. 32.5M can be claimed today and the pie cannot tell me that.

3. 41 of the 46 contracts are cancelable by the sender, covering 106.2M of the 112.8M locked, and six investor contracts have been cancelled since August. Say on the site who controls the sender wallets and where cancelled tokens go.

My question: will the 40.3M reserve go into a Streamflow lock before the xSTREAM swap?

Note for TokenGems: the market cap here ($1.35M) uses circulating supply, while the PUMP and RAY pages use total supply. One definition across pages would help.

$STREAM one detail in Streamflow’s Transfer Contract guide deserves attention: who can change the wallet receiving vested tokens.

the creator can give that permission to the sender, the recipient, both, or neither. that choice becomes permanent once the contract is created.

the guide also explains that transferring a contract moves both future tokens and unlocked tokens that have not been withdrawn. someone changing wallets needs to understand that the full remaining allocation moves with it.

could the team add a simple example to the guide showing these two balances moving to a new wallet? a matching preview before confirmation would also help users understand exactly what they are transferring.

the documentation explains the rules. showing their effect with an example would make them easier for a first-time user to understand.

this observation is based on the guide, not a completed transfer.

$STREAM

I reviewed Streamflow's token vesting and streaming infrastructure for Solana projects on the TokenGems dashboard.

While the underlying contract architecture for immutable linear vesting is structurally solid, there is an explicit UX and operational accounting friction point when handling multi-sig cancellation and clawback updates. Currently, if a project sets up a revocable stream for a developer and terminates it prematurely, the unvested balance routes back to the sender's treasury. However, the transaction ledger on Solscan does not clearly separate the recipient's accrued-unclaimed assets from the clawed-back treasury funds without complex manual logs parsing. Introducing a dedicated, on-chain event log distinguishing 'claimed_to_recipient' from 'clawed_back_to_treasury' would drastically optimize reporting workflows for decentralized operations.

Furthermore, allowing contributors to delegate their SPL governance voting power during a standard 6-month cliff period without unlocking token liquidity would heavily advance user utility.

$STREAM is a gem!

Reviewed Streamflow’s token vesting and streaming infrastructure for Solana projects. The contract architecture for immutable linear vesting is solid, but here is a critical UX and operational friction point during real multi-sig management:

1. Cancellation & Clawback Transparency: When a project sets up a revocable vesting stream for an employee or contributor via Squads multi-sig, if the stream is prematurely cancelled, the unvested balance is automatically returned to the sender. However, the transaction receipt on Solscan doesn't clearly delineate between accrued-unclaimed tokens vs. returned clawback tokens in the event logs without manual parsing. Adding an explicit on-chain event log showing "claimed_to_recipient" vs "clawed_back_to_treasury" would drastically simplify accounting for corporate treasuries.

2. Cliff Period Partial Unlocks: Currently, if a stream has a 6-month cliff, the recipient cannot interact with the stream at all. It would be valuable to allow users to delegate voting power (SPL governance) during the cliff period without unlocking token liquidity. Has the team considered integrating SPL Governance voter weight plugins natively into Streamflow lock contracts?

My take on $STREAM :

Explored Streamflow around their 70% supply burn (699.99M $STREAM burned Sep 23, verifiable on Solscan — supply now capped at 300M). What stands out: a token-operations platform serving 40K+ projects and $660M+ TVL, whose whole pitch is on-chain transparency — yet this token page doesn't surface the burn transaction or the team's vesting schedules. That's the exact proof their product exists to provide.

Suggestion: link the burn tx and live vesting contracts directly on the token page. It would turn the page into a working demo of the product itself.

Question for the team: with the 6-month xSTREAM swap window running, what's the plan for $STREAM liquidity for holders who don't go through verification?

$STREAM I checked the deployed Solana programs instead of the marketing.

The app banner says "audited by 4 major auditors". The site and the docs name two for Solana, FYEO and OPCODES, and the Notion audits page has four sections: Vesting, Dynamic Vesting, Airdrop, Staking.

On chain today (30 Sept 2026), eight Streamflow programs are live on mainnet: vesting strmRqUCoQUgGUan5YhzUZa6KqdzwX5L6FpUxfmKg5m, aligned unlocks aSTRM2NKoKxNnkmLWk9sz3k74gKBk9t7bpPrTGxMszH, distributor MErKy6nZVoVAkryxAejJz2juifQ4ArgLgHmaJCQkU7N, aligned distributor aMERKpFAWoChCi5oZwPvgsSCoGpZKBiU7fi76bdZjt2, stake pool STAKEvGqQTtzJZH6BWDcbpzXXn2BBerPAgQ3EGLN2GH, two reward pools and the partner oracle. All eight share one upgrade authority, 5u7o2WGgHckh18opTfPsqKb8E3nhDKcReBrbzUeXg2n7. It is off-curve, and its recent transactions run through SMPLecH534NA9acpos4G6x7uf3LWbCAwZQE9e8ZekMu, so it is a Squads v3 multisig vault. That is the right setup, and nothing on the site says so. It should.

Two things I could not tie together:

1. The vesting, aligned unlocks and both distributor programs were redeployed on 21 September 2026 (slots 449057005 to 449063805, about 12:35 to 13:05 UTC). Which audit covers the build that is live now? The audits page does not put a commit or a date against a program version.

2. None of the eight programs has a verified build. verify.osec.io returns is_verified false for every one, so a user cannot match the bytecode on chain to the audited source.

Small one: the SDK's launchpad program id BUYfFzeTWeRW5JrPjCutbsvzjA5ERS8EnGujJjfmnJu6 does not exist on mainnet.

Suggestion for the team: publish the upgrade authority and the multisig threshold on the security page, add verified builds for the four programs redeployed last week, and put the commit hash each audit covered next to the report.

$STREAM is a gem!

Tested Streamflow on Solana to lock $STREAM and set up vesting streams.

Phantom confirmed the transactions in under 2 seconds. The cliff vesting setup was also straightforward.

One thing I’d like to see for CSV multi-recipient streaming: check whether recipient ATAs already exist before sending.

A simple pre-flight status in the preview table could help catch failed batch transactions before they happen.

Solid tool for $STREAM operations and token launches.

$STREAM

Checked the STREAM burn on-chain and then the Transparency block on streamflow.foundation. The burn is real: tx 4rbViHbm…hchZNv (23 Sep) burned 699,994,595 STREAM, and the mint now shows supply 299,999,952 with mint authority and freeze authority both null. So the 300M cap is enforced by the token itself, not by a promise.

But the Unlock Schedule chart right under "Total Supply: 300M" has not caught up. Hovering the chart: "Now" shows Total Unlocked 237,417,698 STREAM, and the last point (16 Dec 2027) shows 339,864,227 — more than the whole supply. The pie above it says 61.96% unlocked, which is about 185.9M. Looks like the schedule was not rebased after the burn and the founder's allocation return.

Two questions for the team:

1. Could you link the actual vesting contract IDs for the Investors (27.07% locked) and Contributors (10.71% locked) buckets? Streamflow sells verifiable vesting, so letting holders check the remaining locks themselves would be the strongest proof.

2. The pie shows 61.96% unlocked but 48.52% in circulation. What is the ~13.4% (~40M STREAM) that is unlocked but not circulating, and is it under any lock?