Seesaw Bug Bounty Program#

Version: 2.0.0 Last Updated: 2026-05-19 Platform: Direct submission (admin@palominito.com). Migration to Immunefi planned once protocol revenue + treasury commitments justify their fee schedule — see § 5.6.

1. Program Overview#

Seesaw is a permissionless, on-chain binary prediction market protocol on Solana. Users trade YES/NO shares on configurable-duration binary outcomes (price UP or DOWN) through a fully on-chain order book with Pyth oracle integration.

This bug bounty program is designed to incentivize responsible disclosure of security vulnerabilities in the Seesaw protocol and its supporting infrastructure. The program is currently run directly by the Seesaw security team (see § 6) and uses Immunefi's vulnerability severity classification system as its methodology baseline.

Seesaw is pre-launch and pre-revenue. Rather than pay rewards from a fixed treasury (which would require capital the protocol does not yet have), bounties are paid as a share of the protocol's revenue over a fixed window of days following the fix, calibrated for the pre-launch / alpha tier and scaling up at documented milestones (§ 5.6). This structure aligns researcher incentives with protocol success and removes the upfront-capital constraint that would otherwise force the bounty schedule to be uncompetitive or absent.

Program Goals#

• Identify vulnerabilities that could lead to loss or theft of user funds
• Discover flaws in oracle integration, order matching, or settlement logic
• Uncover authorization bypasses or state corruption in the on-chain program
• Find security issues in off-chain infrastructure that supports the protocol

2. In-Scope Assets#

2.1 On-Chain Program (Primary Scope)#

2.2 Indexer API#

2.3 Web Application#

2.4 Mobile Application#

2.5 SDK and Libraries#

3. Out-of-Scope#

The following are explicitly out of scope for this bug bounty program. Reports on these items will be closed as informational and will not receive a reward.

3.1 Third-Party Dependencies#

• Vulnerabilities in Solana runtime, validators, or the Solana CLI
• Vulnerabilities in Pyth Network oracle contracts or data publishers
• Vulnerabilities in SPL Token program or other Solana foundation programs
• Vulnerabilities in third-party npm packages, Rust crates, or other dependencies (report these to the respective maintainers)
• Vulnerabilities in wallet software (Phantom, Solflare, etc.)

3.2 Social Engineering and Phishing#

• Social engineering attacks targeting team members
• Phishing sites or impersonation of the Seesaw brand
• Attacks that require compromising a user's private key through non-technical means

3.3 Denial of Service#

• Volumetric DDoS attacks against RPC endpoints or API servers
• Resource exhaustion through normal usage patterns (e.g., creating many markets, which is rate-limited by rent costs)
• Crank liveness issues caused by network congestion (this is a known accepted risk; see Section 8)
• Attacks that require spending more in transaction fees than the damage caused

3.4 Other Exclusions#

• Issues that require physical access to a user's device
• Attacks requiring the victim to install malware or a malicious browser extension
• Clickjacking on pages with no sensitive actions
• CSRF on forms that do not perform state-changing actions
• Missing HTTP security headers that do not lead to a direct exploit
• Theoretical vulnerabilities without a working proof of concept
• Issues already reported by another researcher (first report takes priority)
• Issues already documented in the Known Issues section below
• Best practice recommendations without a demonstrated security impact
• Attacks against testnet or devnet deployments only

4. Severity Classification#

Severity is classified according to Immunefi's vulnerability severity classification system, with the following Seesaw-specific examples and guidance.

4.1 Critical#

Definition: Direct loss of funds or permanent freezing of funds exceeding $10,000 (or equivalent in SOL/USDT).

Seesaw-specific examples:

Impact threshold: Any vulnerability that can drain, steal, or permanently lock user funds in a vault, regardless of the amount, qualifies as Critical if the attack is repeatable.

4.2 High#

Definition: Temporary freezing of funds, theft of unclaimed yield or fees, or permanent denial of service to the protocol.

Seesaw-specific examples:

4.3 Medium#

Definition: Smart contract unable to operate at expected levels due to unexpected behavior, or theft of gas/transaction fees from users.

Seesaw-specific examples:

4.4 Low#

Definition: Contract does not function as intended but no funds are at risk. Informational issues with minimal security impact.

Seesaw-specific examples:

5. Reward Structure#

Rewards are denominated in USD and paid in USDT (SPL — the protocol's settlement token). Payment is funded from accumulated protocol revenues per the reservation mechanism described in §5.3.

Funding. Seesaw is pre-launch and pre-revenue. The protocol does not hold a fixed bounty treasury today, and this program does not promise a fixed cash payout for the alpha period. Instead, a portion of protocol-fee revenue is set aside as it accrues to fund this program — see § 5.6. As the protocol matures and that reserve grows, the program is expected to migrate to a conventional fixed-payout schedule keyed to severity and finding validity (also § 5.6). The revenue-share mechanism below is the bootstrap structure, not the permanent one.

The exact awarded amount within a range is determined per-finding using the factors in §5.2.

5.1 Reward tiers (alpha-launch calibration)#

Each window aligns to UTC midnight: it starts at 00:00:00 UTC on day D and ends at 23:59:59 UTC on day D + N − 1, where N is the window length in days. The researcher chooses D — any contiguous N-day window within 12 months of the vulnerability being confirmed and fixed.

There is no floor during the alpha period. If the researcher selects a window in which the protocol earns no fees, the reward is zero. This is a deliberate consequence of the no-fixed-treasury constraint: the researcher controls window selection (§ 5.4) precisely so they can choose a period when the protocol has trading activity. Researchers should not select a window until the protocol is demonstrably generating fee revenue.

These tiers are explicitly calibrated for the pre-launch / alpha period and are designed to be replaced by a fixed-payout schedule at the milestones in § 5.6. Researchers receive the better of (a) the tier in effect at submission time and (b) the tier in effect at fix-deployment time.

5.2 How "revenue" is computed#

5.3 Payment Mechanism (Revenue Reservation)#

Once a report is accepted as valid, the protocol reserves accumulated revenue against the awarded bounty as follows:

• Start time: At the first 00:00 UTC following the moment of acceptance.
• Reservation rate: 100% of protocol revenues accruing from that point forward are reserved for the bounty. Protocol revenues here means the net protocol fees flowing to the addresses in config.treasury_recipients[]. Creator fees, referrer earnings, and any other party-specific fees are not diverted.
• Payout trigger: Once the cumulative reserved amount equals the awarded bounty in USD, the full bounty is paid to the researcher in USDT (SPL) in a single transfer.
• Concurrent reports: If multiple findings are accepted while another is still accumulating, reservations run in FIFO order of acceptance — only one bounty accumulates at a time; the next starts when the prior completes.
• Timeline: Total time-to-payment is a function of protocol revenue throughput. There is no minimum or maximum payment timeline; researchers should expect variability.
• Fix decoupled from payment: The reservation and payout are independent of fix deployment. Fix timelines remain governed by §7.

Where gross_protocol_fees_during_window is the sum of all credits to config.treasury_recipients[0..7] (the eight sharded SPL token accounts that receive the protocol-fee share of every taker fill) during the researcher's chosen window. This number is fully on-chain auditable — anyone can reconstruct it from transaction history.

• Payment is denominated in USD; settlement is in USDT (SPL).
• The awarded amount is fixed in USD at the moment of acceptance.
• Payments are subject to applicable tax reporting requirements.
• No advance payments. No fixed payment-timing SLA — payment timing is determined by the reservation mechanism in §5.3.

6. Submission Guidelines#

6.1 How to Submit#

For the alpha and initial-mainnet period (see § 5.6), reports go directly to the Seesaw security team via one of the following channels — in order of preference:

1. GitHub Security Advisory (preferred): open a private security advisory on the relevant repository under https://github.com/orgs/palominito/repositories — encrypted in transit, routes to the security team, and supports private back-and-forth on the same thread.
2. Encrypted email: admin@palominito.com, encrypted with the team PGP key. The PGP fingerprint and key are published in the repository's security policy.
3. Plain email (only if PGP setup is impractical): admin@palominito.com. The protocol will respond with an encrypted channel to continue the conversation.

Reports submitted via public channels (GitHub issues, Discord, Twitter, etc.) are not eligible for a reward and put users at risk by disclosing the vulnerability before a fix can be deployed. If you accidentally disclose publicly, delete the post and follow up by one of the channels above immediately.

Once the protocol matures past the milestones in § 5.6, Seesaw expects to migrate to the Immunefi platform for standardized triage and payment processing. Until then, submitting directly avoids the Immunefi platform fee and lets the bounty land entirely with the researcher.

6.2 Required Information#

Every submission must include:

1. Vulnerability description: A clear, concise description of the vulnerability and which invariant or security property it violates
2. Affected asset: Which specific asset (on-chain program, API, web app, etc.) is affected
3. Severity assessment: Your proposed severity with justification referencing Section 4
4. Proof of concept: A working PoC demonstrating the vulnerability. For on-chain vulnerabilities, this should be:
   • A Rust test case that can be run against the program, OR
   • A sequence of Solana transactions demonstrating the exploit on devnet/localnet
5. Impact analysis: The maximum potential impact, including an estimate of funds at risk if applicable
6. Reproduction steps: Step-by-step instructions to reproduce the vulnerability from a clean environment
7. Environment details: Solana CLI version, cluster (localnet/devnet), and any other relevant configuration

6.3 Proof of Concept Requirements#

For on-chain program vulnerabilities, the PoC must:

• Compile and run against the current deployed program version
• Demonstrate the vulnerability on localnet or devnet (never mainnet)
• Include all necessary setup steps (account creation, funding, etc.)
• Clearly show the violated invariant or unauthorized state change
• Be self-contained (no external dependencies beyond standard Solana tooling)

For API/web/mobile vulnerabilities, the PoC must:

• Include HTTP requests, scripts, or step-by-step browser/device instructions
• Demonstrate actual impact (not just a theoretical bypass)
• Not require modification of client-side code that would not be possible in production

6.4 Report Quality#

Higher quality reports receive faster review and higher rewards. A high-quality report:

• Identifies the root cause, not just the symptom
• References specific source code files and line numbers
• Maps the vulnerability to the protocol's documented invariants (see the protocol security specification and the invariants reference in Section 10)
• Suggests a remediation approach
• Analyzes whether the vulnerability affects multiple code paths or only one

7. Response SLA Targets#

7.1 Severity-Based Escalation#

8. Responsible Disclosure Policy#

8.1 Researcher Obligations#

By participating in this bug bounty program, researchers agree to:

1. No exploitation: Do not exploit the vulnerability beyond the minimum necessary to demonstrate its existence
2. No data exfiltration: Do not access, modify, or delete data belonging to other users
3. No public disclosure: Do not disclose the vulnerability publicly until the agreed disclosure date
4. No mainnet testing: Do not test exploits on Solana mainnet. Use localnet or devnet only
5. Good faith: Act in good faith and avoid actions that could harm the protocol or its users
6. Single report: Do not submit the same vulnerability to multiple channels

8.2 Seesaw Team Obligations#

The Seesaw team commits to:

1. Safe harbor: We will not pursue legal action against researchers who follow these guidelines
2. Timely response: We will respond within the SLA targets outlined in Section 7
3. Fair compensation: We will pay fair rewards based on the severity and impact of validated findings
4. Credit: We will credit researchers in public disclosures and our security acknowledgments page (unless anonymity is requested)
5. No retaliation: We will not restrict or penalize researchers' access to the protocol for submitting valid reports
6. Transparency: We will communicate openly about fix timelines and any delays

8.3 Disclosure Timeline#

• Day 0: Vulnerability report received
• Day 0-3: Triage and initial assessment
• Day 3-90: Fix development, testing, and deployment
• Day 90: Coordinated public disclosure (or earlier if mutually agreed)
• Exception: If a fix requires more than 90 days (e.g., protocol upgrade with migration), the disclosure timeline will be extended by mutual agreement, not to exceed 180 days

8.4 Coordinated Disclosure Format#

Public disclosures will include:

• Vulnerability description (technical details)
• Impact assessment
• Timeline of events (report, fix, deployment)
• Credit to the researcher (if desired)
• Lessons learned and protocol improvements

9. Known Issues and Accepted Risks#

The following are known issues or accepted design trade-offs. Reports on these items will be closed as informational and will not receive a reward. If you believe you have found a novel exploit vector related to one of these items, please submit it with a clear explanation of how it differs from the accepted risk.

9.1 Crank Liveness (Accepted Risk)#

Description: Markets could stall if no crank operators submit lifecycle transactions (snapshot, resolve, settle).

Why accepted: This is an intentional design choice for decentralization. Operations are permissionless (anyone can run a crank), operators are incentivized with per-operation rewards, and Tuktuk integration provides automated fallback. Multiple distributed operators mitigate single-point-of-failure risk.

Not in scope: Reports showing that markets stall when no crank is running, or that crank operators can be DoS-ed through normal network congestion.

In scope: Novel attacks that could permanently prevent any crank from operating on a specific market even when multiple operators are active.

9.2 No Position Limits (Known Limitation)#

Description: Users can accumulate unlimited shares in a single position. There is no maximum position size in v1.

Why accepted: Full collateralization ensures solvency regardless of position size. Position limits will be considered for v2.

Not in scope: Reports that a large position can be accumulated, or that this creates market manipulation risk through large orders.

In scope: Exploits that leverage unlimited position size to violate a protocol invariant (solvency, conservation, etc.).

9.3 Single Oracle Provider (Known Limitation)#

Description: Seesaw uses Pyth Network as the exclusive oracle provider with no fallback.

Why accepted: Pyth is a decentralized, well-established oracle with multiple data publishers. Multi-oracle support is planned for a future version.

Not in scope: Reports that Pyth could go down or provide stale data (handled by staleness checks and the expiration mechanism).

In scope: Bypasses of the protocol's Pyth validation logic that accept invalid, stale, or manipulated prices.

9.4 Order Book Depth Limit (Known Limitation)#

Description: The order book supports a maximum of 63 bids and 63 asks per market due to on-chain account size constraints.

Why accepted: This is a deliberate trade-off between on-chain storage costs and order book depth. Capacity expansion is planned.

Not in scope: Reports that the order book can be filled, preventing new orders.

In scope: Exploits that cause the order book to accept more orders than its capacity, corrupting state.

9.5 MEV / Front-Running Exposure (Known Limitation)#

Description: Order book operations are visible in the mempool before confirmation, allowing MEV extraction through front-running or sandwiching.

Why accepted: This is inherent to public blockchain transaction ordering. Mitigation strategies (e.g., commit-reveal schemes) are under evaluation for future versions.

Not in scope: Demonstrating that front-running is possible on Seesaw (it is possible on all public-mempool blockchains).

In scope: Novel MEV vectors specific to Seesaw's design that are avoidable without a commit-reveal scheme.

9.6 No Dispute Mechanism (Design Decision)#

Description: Market resolution is deterministic from oracle snapshots. There is no dispute window or governance override.

Why accepted: Deterministic resolution eliminates governance attack vectors and ensures predictable outcomes.

Not in scope: Reports that a market resolved in a way the reporter disagrees with, if the resolution matches the oracle snapshots.

In scope: Situations where deterministic resolution produces an outcome that contradicts the oracle data.

9.7 Equality Resolves as UP (Design Decision)#

Description: When end_price >= start_price, the outcome is UP. This means exact price equality resolves as UP.

Why accepted: This is a documented, intentional design decision. The >= comparison is clearly specified.

Not in scope: Reports that equality resolves as UP.

10. Protocol Invariants Reference#

The following invariants are the core safety properties of the Seesaw protocol. Vulnerabilities that violate any of these invariants are likely to be classified as Critical or High severity.

For the full formal invariant catalog — including the execution-path integrity invariants (INV-X1–X4), all fee and multi-fee-recipient invariants (INV-F1–F4, INV-FEE-T1–T5, INV-REFERRAL-T1–T3), and production source locations — see security/invariants.md.

11. Testing Environment Setup#

To help researchers test against the Seesaw protocol, here is how to set up a local testing environment:

# Find and clone the repository from https://github.com/orgs/palominito/repositories
cd seesaw

# Install Solana CLI tools
# See: https://docs.solana.com/cli/install-solana-cli-tools

# Build the BPF program
cargo-build-sbf

# Run the full test suite (to verify your environment works)
BPF_OUT_DIR=target/deploy cargo test

# Run specific test categories
cargo test --lib                      # Unit tests
cargo test --test property_tests      # Property-based tests
cargo test --test integration_e2e     # End-to-end integration tests
cargo test --test security_authorization  # Authorization tests
cargo test --test security_pda_validation # PDA validation tests
cargo test --test security_error_paths    # Error path tests

Key Areas for Researchers#

12. Frequently Asked Questions#

Q: Can I test on mainnet? A: No. All testing must be done on localnet or devnet. Any exploitation of mainnet, even with your own funds, is out of scope and may result in disqualification.

Q: What if my finding overlaps with a known issue? A: If your finding is a novel exploitation of a known issue that goes beyond the accepted risk described in Section 9, submit it with a clear explanation of the novel aspect. We will evaluate it on its merits.

Q: Can I submit findings about the crank service? A: The crank service is in scope only for vulnerabilities that could lead to unauthorized fund movement or permanent denial of protocol operations. Crank liveness issues are out of scope (see Section 9.1).

Q: What programming language is the on-chain program written in? A: Rust, targeting the Solana BPF runtime. The program does not use the Anchor framework; it uses raw Solana program instructions.

Q: Is the indexer database in scope? A: SQL injection and other database vulnerabilities in the indexer are in scope. However, the indexer database is read-only with respect to on-chain state -- corrupting it cannot affect the on-chain program or user funds.

Q: What if I find a vulnerability in Pyth? A: Report it to Pyth's own bug bounty program. Pyth vulnerabilities are out of scope for Seesaw's program. However, if you find a way to exploit Seesaw using a Pyth vulnerability that Seesaw should be defending against (e.g., bypassing staleness checks), that is in scope.

13. Contact#

• Bug bounty submissions: see § 6.1 (preferred: GitHub Security Advisory; alternate: admin@palominito.com PGP-encrypted)
• Security emergencies: admin@palominito.com
• General questions about the program: admin@palominito.com

For the root security policy and PGP key, see the repository's security policy.