Build SVS-5 through SVS-12 in public and leave your mark in Solana's Open-Source tooling.

About

Last week, Superteam Brazil shipped the Solana Vault Standard (SVS) — a native Solana port of ERC-4626 with four core variants covering public/private and live/stored balance models, a module system for extended features, CLI, and TypeScript SDK.

It's the most complete open-source vault infrastructure on Solana today, but it's not even close to what it can and should be... and that's where the Superteam Earn community comes in 👆

You now have the opportunity to help us extend the solana-vault infrastructure to cover pretty much all major use cases possible across DeFi and RWA! Instead of covering one Ethereum-like standard, SVS will be able to cover multiple ones at once + the extensions, SDK and CLI 🔥 turning EIPs into OPOS.

Eight new standard specs (SVS-5 through SVS-12) are written, reviewed, and are now ready to build. They cover streaming yield, native SOL vaults, multi-asset baskets, vault-of-vaults allocators, async redemptions, credit markets, and tranched structured products. Each spec lives in the repo's docs/ folder with full account structures, instruction sets, and integration patterns.

Your job: pick a standard (up to three at once), build it, and submit a PR that meets the repo's quality bar.

Overview

Build one or more of the extended SVS standards as production-quality Anchor programs with full SDK, CLI, and module integration. Each standard is a self-contained program variant that extends the existing SVS architecture.

Repository: github.com/solanabr/solana-vault-standard

Participants can submit up to 3 PRs (one per standard). Your total contribution across all PRs determines your final ranking.

Rewards

• 🥇 1st Place — $1,500 USDG

• 🥈 2nd Place — $1,200 USDG

• 🥉 3rd Place — $800 USDG

• 4th Place — $300 USDG

• 5th Place — $200 USDG

Total Prize Pool: $4,000 USDG

Rankings are based on total contribution value across all submitted PRs — quality, completeness, and number of standards delivered all factor in.

The Standards

Each standard has a full specification in the repo's docs/ folder. Read them carefully before starting.

• SVS-5 — Streaming Yield (specs-SVS05.md): Continuous yield distribution via token streaming

• SVS-6 — Streaming + Confidential (specs-SVS06.md): SVS-5 with confidential transfer privacy

• SVS-7 — Native SOL (specs-SVS07.md): Vaults that accept native SOL directly (wrap/unwrap handled internally)

• SVS-8 — Multi-Asset Basket (specs-SVS08.md): Single vault holding multiple underlying assets

• SVS-9 — Allocator / Vault-of-Vaults (specs-SVS09.md): Meta-vault that allocates across child SVS vaults

• SVS-10 — Async / ERC-7540 (specs-SVS10.md): Asynchronous deposit/redemption request-fulfill pattern

• SVS-11 — Credit Vault (specs-SVS11.md): Lending vault with borrower management and interest accrual

• SVS-12 — Tranched / Structured (specs-SVS12.md): Senior/junior tranche vaults with waterfall distributions

Start by reading the spec for the standard you want to build, plus these repo docs:

• CONTRIBUTING.md — Contribution guidelines

• ARCHITECTURE.md — Cross-variant design, balance models, math

• PATTERNS.md — Implementation patterns all contributors must follow

• TESTING.md — Testing standards and requirements

• SDK.md — SDK architecture and conventions

• CLI.md — CLI structure and command patterns

What Each PR Must Include

Every submitted standard must be a complete, self-contained PR to the repository. Here's what "complete" means:

1. On-Chain Program (Anchor)

• Full implementation of every instruction in the spec

• Account structures matching the spec's PDA layout

• Events for all state-changing operations

• Error codes with descriptive messages

• Clean CPI interfaces for composability

• Clear comments/in-code docs (following the rest of the codebase)

2. Module Compatibility

This is critical. The SVS repo has a module system (svs-fees, svs-caps, svs-locks, svs-rewards, svs-access, svs-oracle). Your new standard must be maximally compatible with existing modules.

• Integrate every module that applies to your standard

• If a module is not compatible with your standard, document why clearly in your PR description and in the standard's docs

• Do not break existing module interfaces — extend them if needed

3. TypeScript SDK

• Extend the existing SDK to support your new standard

• Follow the SDK patterns established in SDK.md

• Full TypeScript typings, no any types

• Include usage examples

4. CLI

• Add commands for your standard to the existing CLI

• Follow the CLI structure in CLI.md

• All standard-specific operations should be accessible via CLI

5. Testing

Testing should be as thorough as possible:

• Program tests — Unit tests for every instruction using in-code testing standards (Anchor's bankrun or equivalent as used in the repo)

• SDK tests — TypeScript SDK integration tests

• End-to-end tests — Full lifecycle tests (initialize → deposit → operate → withdraw → close), scripts that interact with your deployed program

• Trident fuzz testing — Heavily encouraged. PRs with fuzz tests will score significantly higher

• Follow the testing practices documented in TESTING.md

6. Documentation

• Standard-specific doc file (e.g., SVS-5.md) following the format of existing docs like SVS-1.md

• Update docs/README.md to include your standard

• Update the main README.md if needed

• Update any cross-reference docs affected by your addition

7. Devnet Deployment

• Deploy your program to Devnet

• Include the Program ID and example transactions in your PR description

Evaluation Criteria

• Spec Compliance & Correctness (40%) — Does it implement the full spec? Are all instructions, accounts, and events correct?

• Module Compatibility (15%) — How well does it integrate with existing modules? Are incompatibilities documented?

• Code Quality (15%) — Clean Anchor patterns, proper error handling, follows repo conventions

• Testing (15%) — Coverage depth — program, SDK, E2E, and fuzz tests

• SDK, CLI & Documentation (15%) — Complete SDK/CLI integration, clear docs, updated cross-references

Bonus factors (can elevate your ranking):

• Trident fuzz tests included

• Multiple standards submitted with high quality across all

• Novel optimizations or improvements beyond the spec

• Clean git history with meaningful commits

Submission Requirements

Submit through Superteam Earn with:

1. PR Link(s) — One PR per standard to github.com/solanabr/solana-vault-standard. Maximum 3 PRs per person.

2. Devnet Proof — Program ID(s) and example transaction links for each submitted standard (recommended to be in the PR itself)

3. Twitter Post — Share your submission and tag @SuperteamBR

4. Brief Summary — 3-5 sentences per PR explaining your approach, any design decisions, and module compatibility notes

Important: This bounty will be continuously updated as PRs are merged for the standards in scope. If a standard gets merged from another participant's PR before yours, that standard is no longer available. Check the repo's open PRs and merged branches before starting work on a standard.

Submission bonuses:

1. Deep dive — write in depth about your work - it can be in the PR directly, via a Medium article, X post, any way you like.

2. Video walkthrough — Record yourself going over your implementation and explaining design decisions.

3. Video proof— Record a video of you running all end to end tests and displaying your code actually working.

4. Release post— create something cool to release alongside your new implementation - an animation, cli examples, use cases, feel free to imagine.

Rules

✅ Allowed

• AI-assisted development (must be reviewed, tested, and production-quality)

• Building on top of existing repo patterns and code

• Submitting up to 3 PRs (one per standard)

• Teams submitting under a single account (prize is per submission, not per person)

❌ Not Allowed

• More than 3 PRs per person/team

• Breaking existing tests or functionality in SVS-1 through SVS-4

• Modifying core module interfaces without explicit approval

• Submitting incomplete standards (all sections listed above are required)

Timeline

• Submission Deadline: 21 days from listing

• Review Period: 10 days after deadline

• Winner Announcement: Within 14 days after deadline

• Payment: Within 15 days after winner announcement

Terms & Conditions

• All submissions must be original work

• Code must be open-source (MIT license, matching the repo)

• Winning submissions will be merged and extended by Superteam Brazil

• Non-winning submissions should also be public domain (MIT License prefered)

• By submitting, you agree to potential follow-up collaboration

• Iterate on PR feedback — PRs that evolve based on review score higher

• Judges' decisions are final

Resources

Repository & Specs:

• Solana Vault Standard Repo

• All Specs (docs/ folder)

• Module System Spec

Core SVS Docs:

• Architecture

• Patterns

• Testing

• SDK

• CLI

• Constants

• Errors

• Events

• Security

Solana & Tooling:

• Anchor Docs

• Token-2022 Extensions

• Trident Fuzz Testing

• Solana Cookbook

• ERC-4626 Reference

• Each spec includes (if any) more specific links to either Ethereum-equivalent code or other inspirations

Questions?

• GitHub: Open an issue on the repo, tag @kauenet

• Discord: discord.gg/superteambrasil

• Twitter: @SuperteamBR / @kauenet

Skills Needed: Rust, Anchor, TypeScript, Token-2022, DeFi Architecture

Eligibility: Brazil