Skip to content
>_ vibestarter://docs/08-automatic-signatures

Docs

Protocol

Automatic Signature Policy

When and how the platform's backend issues the signatures that gated on-chain actions require

Backing a raise, launching a raise, and filing or supporting a challenge each require a short-lived signature from the platform's backend. The signature is a compliance permit: it attests that your wallet passed the checks below at the moment of issuance. It authorizes; it cannot execute. The transaction itself is always constructed, signed, and broadcast by your own wallet.

Issuance is automatic

No human reviews, approves, or delays any individual signature request. The backend signs for any wallet that passes — and refuses any wallet that fails — exactly these checks, in this order:

Authenticated session

You are signed in with the wallet (Sign-In-With-Ethereum).

No platform ban

The wallet is not banned. Bans are issued only on the published moderation grounds, each with a recorded reason and audit log.

Sanctions screening

The wallet is screened against the OFAC SDN list (and the Chainalysis sanctions oracle where deployed) on every request. Sanctioned wallets are refused.

Signup completion

The wallet has completed the one-time Starter Card signup, which includes accepting the platform terms.

Geographic restriction

Requests from restricted jurisdictions (US, CU, IR, KP, SY, RU, CN) are refused at the network edge.

Launch signatures additionally require, in the current review phase:

Approved founder application

Reviewed against the published rubric — the one human-judgment step in the system, governed by the Admission & Moderation Policy with published criteria, scoring bands, a review SLA, and an appeal path.

Launch clearance

Third-party launches open only once the platform's incorporation requirements are complete, and each approved founder is individually cleared for launch. Until both hold, launch signatures are refused with a non-personal gating message (VS-S010) — approval status is unaffected.

Founder Raise Terms accepted

Wallet-signature acceptance, verified server-side.

Pilot cohort capacity

During the initial third-party phase the cohort is curated: Wave-1 raises are shortlisted from the pilot pipeline and direct applications under the Admission & Moderation Policy. Among admitted founders a fixed maximum of non-settled raises applies. At capacity, launch signatures are refused with a capacity message (VS-S009) until a slot frees — slots reopen automatically as raises settle, first-come among admitted founders, with no per-request discretion.

What this means

  • No discretion per request. The backend cannot favor, deprioritize, or selectively delay individual wallets: identical inputs produce identical outcomes. There is no queue a human works through.
  • Refusals are rule-shaped. Every refusal maps to a numbered check above, and each check's grounds are published.
  • Signatures are short-lived and scoped. Each expires within minutes, is bound to one wallet and (for participation) one raise contract, and contains no amounts and no transaction data.

NOTE

The stated end-state is that the application-review step is retired in favor of mechanical, published, objective criteria — including mandatory founder identity verification through an independent provider (the platform receives a pass/fail status only, never identity documents). This page will be updated to match exactly what runs.

Companion pages: Admission & Moderation Policy · Metrics methodology