Slingshot: Product Architecture & Progress
Slingshot is a launchpad on Base. Projects issue their own token, publish project information on the token page, and choose one of two raise tiers: a low tier of 5 ETH or a high tier of $50,000. zkTLS verifies that this information is authentic and determines which fields are disclosed. Investors swipe to discover projects, place bids, buy tokens, and track their positions.
Product
Four core capabilities
Product map: by participant
The product broken down by participant: what projects, investors, and the platform each do, and how they connect.
Investor journey
Five steps: landing page swipe → home (banner, trending, favorites) → project page (information, verification status, milestones) → Market (three states) → Portfolio (positions, auctions joined, favorites). Favorites return to the home page.
The five pages from discovery to position, and the main action on each.
Project launch: form, preview, publish
Launch Token is a seven-step wizard. Step 6 is the preview: not a separate page, but the final confirmation before signing. It shows the published project page and all parameters.
Market states
Market has three normal states. A refund for failing to reach the graduation line is an exception, not a fourth state.
- Auction live: allocation remains; investors place bids.
- Sold out: allocation is fully sold, not yet graduated; tokens can be bought.
- Graduated: buy from the pool; testnet pool is live, production V4 Hook is pending.
Refunds & milestone releases: if the auction ends below the graduation line, buyers receive a full refund. After graduation, proceeds are held in escrow and released by milestone; each achieved milestone releases its share. If a milestone is missed, that share is not released; whether it is locked, extended, or refunded to buyers is TBD.
Post-graduation pool: testnet complete, production V4 Hook pending.
Testnet: the graduation pool executor and VFY pairing are complete; BondingCurveSale triggers pool creation on graduation, and LP tokens are permanently burned.
Production: replace the testnet pool with a Uniswap V4 Hook. Liquidity still comes from two sources:
- Token side: pool reserve, i.e. unsold tokens.
- Asset side: graduation proceeds. If the pool is token/VFY, ETH proceeds must first be swapped to VFY [TBD].
Portfolio: three sections
- My positions: quantity, cost, current value, P&L, claim.
- Auctions joined: bid, fill, refund status.
- Favorites: projects saved by swiping.
Verification & System
zkTLS solves two trust problems
zkTLS first solves data provenance, then how the platform uses that data.
Data provenance: the user logs into GitHub, GA4, or Stripe in their own browser. The plugin and notary run MPC-TLS and produce a TLSNotary proof. The proof establishes that the response came from the official backend; credentials and raw data never leave the device.
Platform decision: authentic data does not mean the platform will use it correctly. If GitHub /user returns alice, zkTLS proves that response is authentic; the platform can still attach alice's proof to bob's project, show "verified" after expiry, or accept a failed signature. zkTLS does not cover the platform's verify → extract → compare → output step.
How the second layer works: TEE (Vela/Phala) places the decision in a hardware-isolated enclave and signs it; zkVM (SP1) compiles the decision to Rust and generates a proof. Both approaches prove the same thing: the platform did not alter the decision.
Human boundary: the user operates in their own browser; the plugin produces the proof locally; the notary runs MPC remotely; the platform receives only the proof and disclosed fields; credentials and raw responses stay local.
Our approach: TLSNotary for provenance. GitHub ownership uses a single-proof verification first. For TEE, use Vela; use Phala as a fallback until Vela is ready. For zkVM, use SP1.
Verification metrics
Verification has two layers: project ownership and traffic.
- Project ownership: the GitHub account is controlled by the project.
- Traffic: GA4 is implemented; PostHog and Plausible have no provider yet.
Project ownership: proving a GitHub account
This step proves one thing only: the GitHub account is controlled by the project. The user logs into GitHub in their browser; the plugin turns the /user response into a TLSNotary proof signed by the notary. The platform never sees the password, only the proof and account fields.
A valid proof does not mean the platform will display it honestly. The platform must verify the proof, extract the account ID, bind it to the project, and output the result. That step runs in TEE (Vela/Phala) or is proven with SP1, so others can verify that the platform did not change the code or the result.
The page displays the proven GitHub account, e.g. GitHub: alice. The platform nickname is separate and must not be treated as the GitHub account.
Plugin data capture
Plugin-only: the user logs into the official backend; the plugin proves only the declared request and runs MPC-TLS with the notary. The platform receives the proof and disclosed fields, not credentials.
Metrics: fields and sources
Metrics on the UNIFROG project page:
- Visits — GA4
- Unique visitors — GA4
- Pageviews — GA4
- MAU — GA4
- ARR — Stripe
- 30d retention — Product
- Commits — GitHub
- Holders — BaseScan (on-chain)
- Churn — Stripe
ARR is not the same as 12-month revenue
Two routes:
- A: the data source returns the full period (Stripe
created[gte]/[lt],has_more=false). The platform does not aggregate; one proof covers the result. - B: one proof per month; the TEE appends each record, rejects missing months, computes the Merkle root and total, signs the result, and an independent off-chain implementation recomputes it.
Prefer A. Use B only when the source lacks range queries or monthly audit is required.
Adding the past 12 months gives TTM revenue, not ARR. If the page says ARR, either rename it "verified revenue, trailing 12 months" or compute ARR from current subscriptions.
Evidence status
System architecture: five modules
The system has five modules: frontend (six pages + wallet), backend & data (API, indexer, Postgres), verification (TLSNotary + TEE/zkVM: Vela, Phala, SP1), Base on-chain (contract suite), and authentication & external data sources (GitHub; later GA4/Stripe).
Verification is not a standalone service; it is the flow from frontend initiation to proof generation to project-page display. Module-level status is in the next section.
Project progress: done vs. not done
Status is tracked at the sub-item level. Green means the sub-item currently works; it does not mean the whole module is complete.
| Module | Sub-item | Status | Notes |
|---|---|---|---|
| Frontend Web App | |||
| Frontend | Page framework (landing / home / project / Market / Portfolio) | Done | Six pages open; some modules are still design placeholders |
| Real data integration | Done | Home / project / portfolio pages use the local API | |
| Wallet connection | Done | Standard dApp flow; persists across pages | |
| Buy | Wrapping up | Test wallet/API purchase works; browser-wallet signing pending acceptance | |
| Launch form / preview | Wrapping up | UI and preview done; contract integration in progress | |
| End-to-end integration tests | Wrapping up | Main path is being closed end to end | |
| Backend & Data | |||
| Backend | API / indexer / Postgres | Done | Runs locally; 19 data-layer tests |
| Verification | |||
| Verification | TLSNotary provenance | Wrapping up | 104 unit tests; production notary not connected |
| GitHub ownership | Pending | Provider not written; start with single /user proof | |
| TEE / Vela | Wrapping up | Local Docker signature/aggregation works; production attestation and module-hash binding pending | |
| TEE / Phala (Vela fallback) | Pending | Can start immediately: Docker + Intel TDX attestation + Base verifier | |
| zkVM / SP1 | Pending | Not started; next. Start with single GitHub proof | |
| Traffic (GA4) | Wrapping up | Two GA4 specs; PostHog / Plausible have no provider | |
| Revenue | Pending | Mock pipeline works; real Stripe revenue not run | |
| Base On-chain | |||
| On-chain | Contract suite (testnet) | Done | Deployed on Base Sepolia; Sourcify verified; still expanding |
| New contracts (escrow / fees, etc.) | Wrapping up | Still being written; tests and wiring follow | |
| Contract unit tests | Wrapping up | 116 passing; new contracts still adding tests | |
| V4 Hook / pool (testnet) | Done | Testnet pool created; production V4 Hook pending | |
| VFY pairing (testnet) | Done | Testnet pairing complete; production later | |
| Frontend contract integration | Wrapping up | Launch / Buy integrated; Sell and escrow not connected | |
| Audit | Pending | Audit scope and window not set | |
| Mainnet | Pending | Not deployed | |
| Operations & Go-to-market | |||
| Operations | Monitoring / on-call | Pending | Planned |
| Market | GTM / first launch | Pending | No go-to-market plan yet |
Development stages
The project has three stages:
- Stage 1 (V1): build a testable version and put it in front of users for testing.
- Stage 2 (V2): by the time V1 is shippable, V2 is substantially complete; operate for a few months after launch.
- Stage 3 (V3): decide whether and what to build next based on how the first two stages perform in operation.