Crypto Intelligence Workspace
The crypto workspace is the authenticated Vartovii surface for reviewing a Web3 project before deeper research, a readiness handoff, or a report workflow.
It is designed for analyst use: the page keeps the Trust Score, evidence coverage, source provenance, market data, security context, and next operator step visible in one place. The goal is not to declare a project "safe"; the goal is to show what Vartovii currently knows, what evidence is missing, and where a reviewer should go next.
What The Page Shows
The route is available at:
/app/crypto/:slug
Examples:
/app/crypto/monad
/app/crypto/layerzero
/app/crypto/surge
The first fold is organized around the project identity and the current evidence state:
| Area | Purpose |
|---|---|
| Project header | Shows project name, symbol, stage, short summary, source provenance, and external links when available. |
| Trust Score summary | Shows the current score, risk language, lifecycle stage, and verified dataset count. |
| Search and report actions | Lets the user search another project or open the AI report path from the current workspace. |
| Metric cards | Shows price, market cap, FDV, and development activity where supported by current data. |
| Decision rail | Keeps the score, coverage limits, market surface, token exposure, radar view, and next operator step visible while reviewing the page. |
Downloadable PDF Report
The crypto workspace can export a downloadable PDF report from the project action area. The PDF now starts with a Vartovii Intelligence executive readout before the classic report body. The first page includes a compact Delta Snapshot so readers can see attached historical movement, or a clear missing-history label when prior snapshot data is not attached in Vartovii data.
The default export uses the Vartovii Intelligence template. A printable classic
template is also available from the report menu as Printable PDF and from
the report API with /api/crypto/report/{slug}?template=classic. Classic mode
removes the dark executive readout page but keeps the evidence sections,
disclaimers, and missing-evidence language intact.
The download menu previews the current export boundary before the file is
generated. It calls out the executive readout, report completeness verdict,
source confidence, and evidence action plan, then shows coverage and
current-payload evidence notes when security provenance, freshness, or stage
context are thin. The menu also labels fallback exports as boundary-backed
downloads before the user starts generation, so degraded exports are easier to
interpret when the backend later returns fallback mode.
If the full report pipeline is unavailable, Vartovii returns a fallback PDF
instead of a hard download failure when project data is still available. That
fallback includes a Fallback Evidence Boundary with the requested template,
attached stage and coverage context, security provenance state, and a clear
advanced-section not-attached label. Missing fallback evidence means it is not
attached in Vartovii data; it is not a claim that external evidence does not
exist.
The classic body starts with Report Contents, an Evidence State Summary,
and a Methodology & Evidence Legend. These sections explain how to read
attached evidence, expected gaps, stage-dependent inputs, Trust Score,
coverage, source freshness, lifecycle stage, missing-evidence labels, and
readiness boundaries before the detailed evidence tables.
The evidence-state summary distinguishes current-payload states such as Ready
evidence, Missing but expected, Stage-dependent, and Not attached in Vartovii
data. A not-attached label means the current Vartovii payload does not include
that evidence; it is not a claim that external evidence does not exist.
The Report Completeness Verdict then labels the report as Usable with
caveats, Partial evidence mode, or Gap-list mode based on coverage, source
confidence, security provenance, and open evidence gaps. This is a report
usability label for the current payload, not a project-quality conclusion.
It also shows Reviewer readiness, which counts required reviewer evidence
packets separately from dataset or pillar coverage. For example, a live-token
project can have full pillar coverage while still needing canonical
contract/source evidence, admin-control proof, audit scope, remediation status,
or source-freshness attachments before a stronger handoff.
Security source labels or rating metadata can support security context, but the
reviewer-readiness packet still remains incomplete until security evidence
details such as audit scope, covered contracts, dates, or remediation status are
attached in Vartovii data.
Attached security evidence can include audit or review packets as well as
non-audit security provenance such as attestations, certifications, compliance
reports, or bug bounty program details when those fields are present in
Vartovii data. These rows are provenance context for the report workflow; they
do not mean Vartovii performed a formal audit, verified remediation, or
confirmed project safety.
The Report Package Profile then explains whether the current payload reads
like a live-token analyst report, tokenless readiness profile, security
readiness packet, or gap-list report profile. These labels are reading aids and
do not enforce access, user plans, or gated report behavior.
The Evidence Action Plan then front-loads the highest-priority reviewer
evidence requests from the same normalized data-room checklist used later in
the report. These priorities describe what to attach before the next refresh;
they are not audit severity, legal assurance, investment advice, or project-risk
ratings.
The Reviewer Handoff Summary then turns that action plan into a short
reader workflow: how to use the PDF, which proof currently blocks stronger
conclusions, which gaps are stage-dependent, and which legal-safe boundaries
must stay visible. It is a trust-intelligence handoff aid, not a formal audit,
legal conclusion, investment recommendation, or claim about evidence outside
Vartovii data.
The PDF also includes a Source Confidence & Freshness readout before the
detailed evidence matrix. It groups source families by attached labels,
freshness mix, and confidence state so readers can see which source rows are
ready, partial, stale, or not attached in the current payload.
It also includes an Evidence Freshness & Attachment Matrix before the
executive narrative so readers can quickly see which proof is attached, where
freshness metadata is missing, and what data-room evidence should be attached
next. Missing proof remains a Vartovii payload gap and is not treated as proof
that external evidence does not exist.
The PDF also includes Evidence Coverage Delta before the executive
narrative. This section compares the current payload with the latest attached
historical snapshot for Trust Score, evidence coverage, source families,
security provenance, and tracked missing pillars. If a previous snapshot is not
attached, the report labels that historical delta as not attached in Vartovii
data instead of inventing zero movement. If the primary report aggregator is
degraded but historical snapshots remain available, the PDF can still use those
attached snapshots for the delta and trend sections.
Historical snapshot rows are normalized before rendering: date and decimal
values are made report-safe, legacy score columns can support previous
score-breakdown context, and coverage metadata is derived only from positive
attached snapshot values. Zero-valued legacy metrics are not counted as attached
coverage evidence.
Attached history can use either snake_case fields or report-payload camelCase
aliases such as trustScore, priceUsd, dataCompleteness,
sectionSources, sectionFreshness, surfaceContract, securityEvidence,
contractAddresses, sourceLinks, and adminControls. Vartovii normalizes
those fields before trend, delta, and historical-context quality sections read
them.
The daily historical snapshot contract keeps missing market, TVL, and price
values missing instead of exporting placeholder zeroes. When attached, history
can also preserve project stage, coverage, source-family, and surface-context
metadata for richer future trend comparisons.
The PDF then includes Historical Context Quality, which states how many
snapshots are attached and whether trend or current-vs-previous delta movement
is usable. When attached, it can also show latest report-context attachment
coverage for the snapshot. Missing history stays a Vartovii data gap and is not
converted into zero movement.
The readout summarizes:
- Trust Score and risk language
- lifecycle stage
- evidence coverage and missing pillars
- source-family provenance
- security or audit provenance state
- readiness caveats and next review context
- reviewer-readiness packet completeness separate from dataset coverage
- attached-signal, scorecard-gap, and freshness-gap counts from the report data completeness scorecard
- attached historical movement for Trust Score, evidence coverage, and security provenance when a prior snapshot is available
The first-page scorecard-gap count is separate from the top evidence requests. A report can show full pillar coverage or low scorecard gaps while still asking for reviewer follow-ups such as canonical contract/source evidence, admin-control proof, audit scope, remediation status, or independent data-room attachments. Those requests mean the evidence is not attached in the current Vartovii payload; they are not claims that external evidence does not exist.
The classic body also includes a report section coverage map. This map shows
which crypto evidence areas are included in the PDF and whether their current
inputs are attached, partial, pending, or not expected for the project's stage.
It also shows descriptive package labels such as Basic Snapshot, Analyst
Report, and Security Readiness Packet; these labels describe report packaging
only and do not imply billing enforcement.
When official documentation provenance is attached for a tokenless or
pre-launch project, the PDF can use Security Readiness Packet packaging even
though live-token market assumptions remain disabled. That label means the
current Vartovii payload includes security, contract/source, or admin-control
evidence for reviewer handoff; it is not a formal audit, safety guarantee,
legal assurance, or investment conclusion. Missing source freshness or missing
historical snapshots still remain visible evidence gaps.
If Vartovii attaches an observed or fetched date for official documentation,
the PDF can use that as source-freshness context. That date means Vartovii
observed the source for the current payload; it is not automatically the
source document's publication date or an audit date.
Near the top of the classic body, the PDF includes an Executive Narrative
that summarizes the current analyst verdict, strongest available signals, open
evidence gaps, and next reviewer actions from the normalized Vartovii report
payload. This readout is decision support only; it does not claim project
safety, investment suitability, independent verification, or formal audit
coverage.
The PDF also includes a Missing Evidence Summary that groups current
payload gaps into Critical missing, Useful to attach, Stage-dependent, and Not
expected for this stage. These labels help readers understand what to attach
next for the report workflow; they are not audit severity, investment advice,
or claims about evidence outside Vartovii data.
The PDF also includes Evidence Gap Prioritization after the executive
narrative. It ranks reviewer inputs such as security provenance,
contract/source links, historical snapshots, source freshness, and
admin-control evidence so a reader can see what should be attached or refreshed
next. Missing proof is framed as a Vartovii payload gap, not a claim that the
evidence does not exist externally. Priority labels such as P1 Handoff blocker,
P2 Confidence driver, and P3 Monitor describe data-room urgency for the report
workflow, not audit severity or investment risk.
When contract/source-link or admin-control evidence is attached in the current
Vartovii payload, the PDF shows that attached state without exposing raw URLs or
addresses in the downloadable report.
The PDF then adds a Reviewer Data Room Checklist that turns required
evidence coverage into evidence packets with current state, attachment request,
priority, and boundary copy. These priorities describe reviewer handoff urgency
only; they are not audit severity labels, legal conclusions, investment advice,
or claims that missing external evidence does not exist.
The project payload normalizer standardizes common contract/source/admin inputs
into report-facing contract_addresses, source_links, and admin_controls
fields so the PDF can distinguish attached evidence from missing reviewer
inputs.
It also recognizes common nested or list-form aliases, including deployed
contract lists, token contract fields, repository links, GitHub link maps,
security admin-control maps, governance multisig metadata, and timelock or
upgrade-control fields. Explorer and source-verification metadata, such as an
attached explorer contract address or verified source URL, can also satisfy the
contract/source attached-state check when present in Vartovii data.
Source-inventory rows with repository or source URLs can also count as attached
source-link evidence, while deployed contract addresses still need separate
confirmation before contract/source coverage is complete. It also accepts
forensics-shaped admin-control context such as owner-renounced state, proxy
admin, Safe/multisig, timelock controller, pause role, upgrade role, and
access-control roles when those fields are attached in Vartovii data. This
reduces false missing-evidence labels when the current Vartovii payload already
has reviewer evidence in a non-canonical shape. These attached states remain
evidence indicators only; they are not audit conclusions, investment advice, or
claims that deployed code is safe.
CamelCase contract/source payloads, such as deployedContracts,
sourceVerification, contractAddress, chainName, sourceCodeUrl,
verifiedSourceUrl, and verificationUrl, are normalized into the same
attached-state model when present in Vartovii data.
When deployed contract evidence is attached without repository or source-code
links, the report can show contract/deployment provenance while still asking
for source-code or repository evidence before treating contract/source inputs
as complete. In Required Evidence Coverage, the PDF labels contract/source
coverage as complete, partial, or missing so readers can see whether deployed
contract evidence and source/repository evidence are both attached without
exposing raw addresses or URLs.
Object-shaped admin-control payloads, such as owner, proxy, Safe, timelock, or
access-control role objects, are normalized into the same attached-state model
when the relevant fields are present in Vartovii data. The report does not print
raw control addresses or object payloads in the narrative.
CamelCase admin-control payloads, such as adminControls, ownerAddress,
proxyAdmin, safeAddress, timelockController, pauseGuardian, and
upgradeAuthority, are normalized into the same report-facing attached-state
model when they are present in Vartovii data. This helps the report avoid false
missing-evidence labels for common explorer or forensics payload shapes.
CamelCase security evidence payloads, such as securityEvidence,
auditReports, securityReviews, securityAssessments, reportTitle,
auditFirm, coveredContracts, reportPublishedAt, and remediationStatus,
are normalized into the same report-facing provenance rows when attached. They
remain evidence indicators only, not Vartovii audit conclusions or safety
claims.
A single admin-control signal, such as only a pause role, is treated as partial
control-surface provenance. The report can show that context, but it still asks
for additional owner, proxy, multisig, timelock, pause, upgradeability, or role
evidence before treating the admin-control packet as review-ready.
Required Evidence Coverage also labels admin-control coverage as complete,
partial, or missing. Partial admin-control coverage still asks for owner,
proxy, multisig, timelock, pause, upgradeability, or role context before a
stronger reviewer handoff; it is not a safety, custody-quality, upgrade-risk,
legal, investment, or audit conclusion.
The downloadable report still shows only the attached/missing state and does not
print raw contract addresses, repository URLs, or reviewer source URLs.
The generated narrative receives only normalized attachment states for those
readiness inputs, so it can mention whether contract/source or admin-control
evidence is attached without exposing raw contract addresses or repository URLs.
It also receives compact coverage and source-freshness context from the current
payload, so AI narrative copy can distinguish attached source labels, missing
source families, and missing freshness metadata without inventing dates.
When source-family provenance is already attached in the project payload, the
report keeps those labels and supported date aliases visible as current
Vartovii data, including common source-family maps such as source provenance,
source family, source, or evidence-source payloads. This source context is a
provenance indicator only; it does not turn attached links into verified truth,
audit coverage, legal assurance, safety, or investment advice, and raw source
URLs stay out of the PDF narrative.
The classic body now includes a Narrative Input Summary that shows the
sanitized coverage, source/freshness, readiness-evidence, and prompt-boundary
states available to the generated narrative. It does not expose raw prompts,
source URLs, contract addresses, or internal traces.
If narrative generation is unavailable for an export, the PDF keeps the report
usable by pointing readers to deterministic sections such as Trust Score,
Evidence Quality Matrix, Source Provenance, Security Readiness Packet, and
evidence gaps instead of exposing provider errors or raw internal details.
The PDF then adds an Actionable Review Checklist that turns those priority
gaps into concrete next steps for analysts and project teams before the next
report refresh. The checklist improves report coverage and reviewer handoff;
it is not a formal audit result, safety claim, or investment conclusion.
The next PDF section, Required Evidence Coverage, separates required
reviewer inputs, cited-source metadata, and stage-dependent context for the
current project stage. For tokenless or pre-launch projects, the report can
show readiness context without inventing live-token market evidence. Attached
contract/source-link and admin-control evidence is shown as readiness context,
not as a formal audit result or safety conclusion.
The Security Readiness Packet uses the same required-evidence contract for
reviewer handoff inputs, including source freshness metadata when cited sources
need date context.
Near the top of the classic body, the PDF also includes a Data Quality &
Missing Inputs readout. It summarizes coverage, source-family provenance,
tracked missing inputs, security provenance state, historical trend evidence,
and report confidence context before the detailed evidence tables. Missing
inputs are described as Vartovii data gaps, not claims that the evidence does
not exist outside the current payload.
The PDF then includes a Report Data Completeness Scorecard. This section
maps each registry-backed report signal to review priority, evidence
attachment, freshness, and the next data-room attachment that would improve
report quality. It is a completeness map, not an audit finding, investment
conclusion, or proof that missing external evidence does not exist.
The PDF then includes Report Improvement Opportunities. This section turns
current coverage gaps, missing freshness metadata, stage-aware market context,
and reviewer handoff inputs into the next data attachments that would improve
the report. These opportunities are coverage guidance only; they are not audit
findings, legal conclusions, safety claims, or investment advice.
The PDF also includes a Project Data Gap Backlog. This section translates
report-facing gaps into product-facing data collection work such as
contract/source canonicalization, admin-control mapping, detailed security
evidence, historical snapshots, source freshness, and Trust Graph edge
confidence. These backlog rows include a work type so readers can distinguish
missing evidence, partial evidence, and history-storage follow-up work. They
describe what Vartovii should collect or normalize next; they are not audit
findings, legal conclusions, safety claims, or investment advice.
The PDF also includes a Trust Score Drivers & Limits section that explains
which score pillars are supporting, moderate, or limiting signals and whether
their evidence context is attached. Pillar scores are directional trust signals,
not guarantees of safety, completeness, investment suitability, or formal audit
quality.
The classic report body uses section-level page-break guardrails and striped
evidence tables so long downloadable reports remain easier to scan in both the
default Intelligence PDF and the printable classic export. These layout
improvements do not change the underlying report data, disclaimers, or missing
evidence language.
Long exports also include compact running page context on the classic body
pages: report family, project name, template mode, report date, and page number.
The dark Intelligence cover remains clean, while later pages are easier to
navigate after downloading, printing, or sharing.
Large evidence sections also include compact At a glance readouts before
the detailed rows, and very long table cells are clipped after the core
evidence boundary is visible. This keeps dense reports scannable while
preserving the same source-state and missing-evidence wording.
The PDF also includes source provenance labels from the current report payload
so readers can see which source families are attached without exposing raw
source URLs in the downloadable report.
It also includes a Source Citation Appendix with sanitized source labels and
freshness context when the current payload includes source dates. The appendix
also labels each citation as Fresh, Updated, Stale, or Not attached based only
on attached freshness metadata. If freshness metadata is missing, the PDF labels
that gap instead of inventing a timestamp. Raw source URLs and internal
collection traces are not exposed in the downloadable report.
Vartovii can also recognize common source freshness aliases, including market,
GitHub, DefiLlama, funding, tokenomics, security, and
source_freshness.<family> timestamps. Non-date values such as URLs, contract
addresses, and source labels are ignored instead of being rendered as freshness.
When the current payload has section-level freshness metadata, the PDF can use
that date for labeled source rows that do not carry their own row-level date.
The report still leaves freshness missing when no source or section timestamp
is attached. If a source-family label itself is missing, the report treats that
as a source provenance gap first rather than counting it as a missing freshness
date. Freshness and confidence grades only apply after a source label is
attached.
It also includes an Evidence Quality Matrix that summarizes each report
signal's evidence state, freshness, and follow-up action. Missing evidence stays
visible as not attached in Vartovii data rather than being inferred or filled
with placeholder metrics.
It also includes a Security Provenance Appendix that summarizes attached
security/audit source-family labels, rating metadata when available, and the
current security-evidence boundary without exposing raw security URLs. When the
payload includes security evidence labels, providers, scopes, or dates, the PDF
shows those details as provenance context while keeping the non-audit boundary
visible. The security evidence table also labels whether each row is
label-only, partial, or reviewable detail and lists missing details such as
provider, scope, date, or remediation status when they are not attached in the
current Vartovii payload.
Vartovii also recognizes common audit aliases, such as audit report lists,
security audit-report maps, security-review payloads, reviewer/security-firm
fields, completion or publication dates, and single audit-report URLs, and
normalizes them into the same evidence state. Covered-contract lists are
summarized as attached references instead of printing raw contract addresses.
An audit label or single audit-report URL can appear as attached provenance,
but the report still treats security depth as incomplete until reviewable
details such as provider, scope, report date, or remediation context are
attached in Vartovii data.
Singular audit objects such as audit, audit_report, or security.audit
can also be normalized when they include attached labels, providers, scopes,
dates, or remediation context.
These details support provenance and reviewer handoff only; they are not a
formal audit result, verified safety claim, or investment recommendation.
When security source labels or rating metadata are attached, the PDF keeps that
state consistent across the readout, coverage map, evidence matrix, and evidence
gaps. Missing count-style metrics render as not reported instead of zero when no
positive evidence is attached.
The generated narrative follows the same rule: missing team-size evidence is
described as not attached in Vartovii data, not as a zero-member team.
The classic body now includes Trust Graph context from the current report
payload, including related-entity and holder-preview state where available.
Related entities are directional evidence signals, not proof of endorsement,
control, or security quality.
The PDF also includes a Security Readiness Packet summary for pre-audit
handoff. It lists the current readiness state, visible evidence signals, proof
gaps, and reviewer inputs such as contract/source links, audit scope,
admin-control evidence, disclosure contact, and incident-response ownership.
The PDF also includes a Trend & Freshness Appendix that shows the generation
date, attached history window, Trust Score movement, and market movement when
historical snapshots are available. If trend evidence is not attached, the PDF
labels the gap rather than filling in inferred zero movement.
It also includes short signal notes for high-context areas such as GitHub
activity, Trust Graph context, security provenance, and tokenomics or
stage-aware fallback boundaries.
AI narrative sections use fixed headings and an evidence-boundary caveat, and
Vartovii removes raw source URLs or contract addresses from that narrative
before rendering the downloadable PDF.
The PDF download menu also previews what the export includes, shows the current
coverage state, shows the current cover profile label, and surfaces all
applicable evidence notes such as thin coverage, missing security provenance,
missing freshness, or stage-aware fallback before the file is downloaded. The
cover profile is a reading aid for the current payload, not a billing tier,
investment conclusion, or audit label.
The Intelligence PDF first page also lists top evidence requests from the same
data-room checklist used in the report body, so readers can immediately see
which security provenance, source freshness, contract/source, or admin-control
inputs would improve the next report refresh. These requests are current
payload gaps and reviewer attachments, not audit findings, investment
conclusions, or claims that external evidence does not exist.
The same first page now includes a compact Data Backlog Next Step hint. It
summarizes the first product-data follow-up, such as attaching missing evidence,
completing partial evidence, persisting history snapshots, or monitoring only.
The detailed product-data follow-ups remain in the report body; the first-page
hint is a triage aid and does not expose raw source URLs or contract addresses.
When security or audit evidence is unavailable in the current payload, the PDF and tokenless dashboard surfaces label it as not attached in Vartovii data. That wording does not mean an audit does not exist; it means the current Vartovii report payload does not include reviewable audit, security tier, or security provenance evidence.
The PDF is based on available Vartovii data and public evidence signals. It is not a formal smart contract audit, investment advice, legal advice, or a guarantee that vulnerabilities do not exist.
Evidence Sections
The workspace is intentionally evidence-first. Each major section should either show supported data or explain the missing state.
Market Performance
The market panel embeds a TradingView-style chart for live-token assets where a supported symbol is available. If the embedded chart is slow, blocked, or cannot render, the panel should still provide an explicit next action such as opening the external TradingView view.
This prevents a blank chart from being interpreted as missing project data.
Trust Graph
The Trust Graph read model shows related-entity context derived from available project evidence. It can include investors, funding links, organization links, source-family coverage, and holder-preview availability.
When no graph edges exist, the workspace shows a low-coverage state instead of inventing relationships. Related entities are directional evidence signals, not proof of endorsement or control. When a related entity comes from an attached source family, Vartovii may attach a conservative edge evidence label and freshness date. This helps distinguish source-backed relationship context from missing graph metadata, but it is still not a claim that the relationship is endorsed, controlled, or independently verified. If a graph edge only has a meaningful source label, the downloadable report can show that source-label attachment as relationship provenance. This reduces false missing-data labels, but it is not a confidence score, endorsement, formal due-diligence result, or proof of control.
Security
The security section shows linked audit or security provenance when Vartovii has source evidence for it. Supported examples include Dropstab security metadata and official/public audit evidence attached to the project profile.
If no current audit coverage is linked, the page should say that coverage is not available in the current Vartovii payload. That is different from saying the project has never been audited.
Fundraising And Backers
The fundraising panel summarizes known rounds, total raised, lead investors, and backer-quality indicators when funding data is available. These signals help contextualize project quality, but they do not replace technical review, tokenomics review, or legal diligence.
Token Unlocks
The unlock panel shows the vesting schedule and unlock status when source data is attached. When allocation details are unpublished, the workspace labels the schedule as unavailable or locked rather than filling in assumptions.
Whale Watch
Whale tracking is only shown when supported on-chain contract data is available. If tracking is unavailable, the panel explains that a live fallback requires supported on-chain contract data.
Community
Community signals summarize visible social reach, influence quality, and social
dominance where current sources provide enough data. A tiny positive social
dominance value may render as <0.01% rather than 0.00% so weak-but-present
signals are not hidden.
Stage-Aware Project Modes
Vartovii separates project stage from project quality. The workspace can render different evidence expectations depending on the current lifecycle state.
| Stage | Expected behavior |
|---|---|
| Live token | Market cards, token exposure, chart, unlocks, and holder/whale context may be relevant. |
| Tokenless | The page focuses more on project identity, funding, development, security posture, and public traction. |
| Pre-launch | The page treats missing market data as expected and emphasizes readiness, fundraising, security, and launch evidence. |
This stage-aware behavior helps avoid false penalties when a project is real but does not yet have a tradable token.
Search And Project Lookup Behavior
The search box supports project lookup by project name or ticker. When multiple projects share a ticker or name, the selected result should resolve to a supported Vartovii project payload.
If a selected project cannot be materialized, the workspace displays a project lookup message and offers a default project action. This usually means the current data snapshot does not contain a supported intelligence payload for that slug yet, not that the project is invalid.
Readiness Report Handoff
Security readiness workflows can open a dedicated readiness route:
/app/crypto/:slug/readiness
That route turns the current project evidence into a pre-audit readiness preview: evidence coverage, missing proof, readiness gaps, and reviewer-ready next actions. It does not replace a formal smart contract audit, legal review, investment review, or incident-response review.
Analyst Workflow
Use the crypto workspace as a first-pass review loop:
- Search for the project and confirm the intended result.
- Read the Trust Score, stage, coverage basis, and decision rail together.
- Check market and token data only when the project is a live-token asset.
- Review security provenance and missing evidence before relying on the score.
- Use the Trust Graph to see related entities and source coverage.
- Open the readiness report route when a reviewer, founder, investor, or partner needs a structured pre-audit handoff.
Limits And Disclaimers
Crypto intelligence in Vartovii is based on available data and attached source evidence. Missing data is shown as missing, low coverage, or unavailable rather than filled with inferred certainty.
The workspace is not legal advice, investment advice, a guarantee of safety, or a formal smart contract audit.