Security Readiness
Vartovii currently has two distinct Security Readiness surfaces. They share a pre-audit purpose, but they do not yet share the same runtime contract.
| Surface | Current behavior |
|---|---|
| Dashboard readiness preview | The existing /app/crypto/:slug/readiness route renders a Trust Score-based pre-audit preview from the current crypto project payload. It does not expose security_readiness.v1 or return the four private-pilot readiness states. |
| Private-pilot Security Readiness Brief | A manually delivered, reviewer-approved brief built from the stable security_readiness.v1 advisory contract. It is separate from the current dashboard route. |
This distinction is intentional. Public documentation must not imply that the dashboard readiness preview already consumes the new service contract.
Dashboard Readiness Preview
The current dashboard route is:
/app/crypto/:slug/readiness
It helps users inspect existing project context, Trust Score-based evidence coverage, missing proof, next actions, and a reviewer handoff summary. It is a product preview, not the manually delivered private-pilot brief described below.
Manually Delivered Private-Pilot Brief
The private pilot is intended for a crypto founder or operator preparing for an audit, grant, listing, fundraising round, integration review, or external security handoff.
The outcome is a bounded evidence brief that shows:
- the current readiness state, confidence, and evidence coverage;
- which evidence categories are attached or missing;
- evidence-bound concerns and a hardening checklist;
- sources, timestamps, reviewer inputs, and the delivery boundary.
Private-pilot pricing is $299–$999, depending on scope and evidence volume. Scope can be reviewed asynchronously. No sales call is required, and any call or delivery debrief is optional.
security_readiness.v1
security_readiness.v1 is the deterministic advisory contract used for the
manually delivered brief. It does not change the canonical crypto Trust Score
and does not mutate the source project payload.
Readiness States
| Contract state | Customer-facing meaning |
|---|---|
READY_FOR_AUDIT | Ready for audit handoff: coverage is strong and no high-risk evidence is visible. This does not mean the project is secure. |
NEEDS_HARDENING | The evidence is usable, but material proof or control gaps should be closed before external review. |
HIGH_RISK | A severe evidence-bound concern requires manual reviewer escalation before customer-facing delivery. |
INSUFFICIENT_EVIDENCE | Coverage is below 40% or required identity/source anchors are missing. The response is gap-only rather than a full brief. |
READY_FOR_AUDIT requires at least 80% category coverage, no high-risk concern,
and minimal missing evidence. All other usable payloads are classified as
NEEDS_HARDENING.
Evidence Categories
| Contract key | Evidence reviewed |
|---|---|
source_verification | Contract or program addresses, verified source links, and build/deployment references. |
authority_governance | Admin keys, multisig, timelock, upgrade, treasury, and emergency-control evidence. |
audit_coverage | Audit scope, reviewer, reviewed-code date, remediation status, and provenance. |
code_dependency_posture | Repository activity, tests, CI, dependency freshness, and public development signals. |
protocol_exposure | Chain, oracle, bridge, vault, keeper, relayer, and integration exposure. |
incident_reputation_context | Security contact, disclosure process, bounty, incidents, and postmortems. |
Missing categories remain visible. Vartovii does not infer absent audit, source, admin-control, disclosure, or dependency evidence.
Intake
Required intake:
- project name or slug;
- review context;
- at least one website, repository, source, contract/program, or audit anchor.
Recommended intake:
- chain and contract/program scope;
- official audit or security documentation;
- admin-control, treasury, multisig, timelock, and upgrade evidence;
- security contact, disclosure policy, incident, or bounty information.
Submit only public-safe evidence or customer-provided material that you are authorised to share. Do not send private keys, credentials, secrets, or unapproved private repository content.
Manual Review and Delivery
Every full brief requires human review before delivery. The reviewer confirms that:
- project identity, context, and source anchors are present;
- readiness states and concerns are supported by attached evidence;
- missing proof remains visible;
- customer-provided material is distinguished from public sources;
- the non-audit disclaimer and prohibited-claim boundaries are intact.
INSUFFICIENT_EVIDENCE produces a gap-only intake response. HIGH_RISK
requires reviewer escalation and is not automatically approved for delivery.
Consent and Privacy
Private-pilot participation is private by default. The requester must confirm that they have the right to submit the project and included materials for review. A project name, logo, quote, result, or case study is published only with separate written consent.
Read the public Privacy Notice for the accepted data, storage providers, 90-day inquiry retention, 180-day post-pilot retention, deletion process, analytics disclosure, and data-subject request channel.
Limitations
The private-pilot brief and dashboard preview do not:
- perform or replace a formal smart contract audit;
- prove that all contracts, deployments, or vulnerabilities were reviewed;
- certify that a project is secure or suitable for investment;
- provide legal, investment, tax, incident-response, or security assurance;
- include checkout, CRM automation, billing, a customer portal, product automation, an audit engine, or exploit simulation.
The canonical boundary is:
This brief is based on available evidence and is not a formal smart contract audit, legal advice, investment advice, or security assurance.