Token distribution on Stellar — one 32-byte commitment, however many recipients.
A project on Stellar that wants to pay 10,000 wallets — an airdrop, retroactive yield, a contributor payout — normally has to send 10,000 transactions and keep 10,000 records on the ledger. The issuer pays for all of it up front, whether or not anyone claims.
YieldStream reverses that. The recipient list is hashed into a single 32-byte Merkle root. The issuer commits that root on-chain and escrows the token pool. Each recipient then proves they belong to the list with a short cryptographic path — about 14 hashes for a 10,000-person list — and pays for their own claim. Whatever is unclaimed when the campaign expires sweeps back to the issuer in one call.
The issuer pays for one commitment. The ledger stores a root, not a roster — the recipient list never goes on-chain. Each claim does write its own ledger entry today; contract issue #13 tracks packing those markers into a bitmap so a 10,000-claim campaign costs ~40 entries instead of 10,000.
| Repo | Language | What lives there |
|---|---|---|
yieldstream-contract |
Rust / Soroban | The distributor contract: campaign creation, escrow, proof verification, claims, cancel, sweep. RFC 6962 domain separation, sorted-pair proofs, 21 tests, pinned JSON test vectors. |
yieldstream-sdk |
TypeScript | Client for building trees off-chain, generating proofs, and talking to the contract. Conformance-pinned to the contract's vectors. |
yieldstream-app |
Next.js / Tailwind | Protocol site, the documentation site, issuer dashboard, and the wallet-connected claim UI. |
They connect in this direction:
recipient CSV → yieldstream-sdk (build Merkle tree)
↓ 32-byte root + proofs
yieldstream-contract (escrow + verify + pay out)
↑
yieldstream-app (issuer uploads, recipient claims)
The SDK's hashing core and the app's dashboard are deliberately unimplemented — they are the work the contributor backlog exists to fund. The contract is the finished piece and is deployed.
Honest version, so nobody wastes a cycle on it:
- Contract: functional, testnet-deployed, full lifecycle exercised on-chain. Not audited. Do not custody real funds with it yet.
- SDK: scaffold with conformance tests written as the acceptance criteria. Core hashing is open contributor work.
- App: landing page live; dashboard and claim UI open contributor work.
- Mainnet: not deployed. Planned after a first external review.
Work is split into three complexity tiers, each worth a fixed reward in the Drips Wave program:
| Tier | GitHub label | Typical scope |
|---|---|---|
| Trivial | tier-100 |
Docs, a single validation check, UI copy, one test vector |
| Medium | tier-150 |
A bounded feature inside one module |
| High | tier-200 |
Storage redesign, cross-repo features, new subsystems |
Read an issue, comment to request assignment, then open a PR. Every repo runs
CI on the branch, and the review bar is stated in each issue's acceptance
criteria: cargo fmt --check, clippy -D warnings, and the full test suite for
Rust; typecheck, tests, and build for TypeScript.
Start here: contract backlog · SDK backlog · app backlog
Participation across all three repos is governed by the code of conduct.
| Owner / lead | @CHASE3020 |
| Security reports | Use private vulnerability disclosure — see each repo's SECURITY.md |
| Triage commitment | Respond to applications and PRs within 48h; review within 5 days |
Dual MIT / Apache-2.0 across all three repositories.