—files
Input files counted for each operation
YunyuTrace service overview
Signed PDF evidence, independent verification and authorized version history for applications.
—B
Total input bytes in the selected period—IPs
Current UTC day · deduplicated per project—calls
Signing plus verification in selected period—regions
Selected period · by source IP locationIP activity by province in China
Loading the map of China
Map data: Alibaba Cloud DataV GeoAtlas
Daily business calls Last 14 days
Waiting for statistics
Beijing calendar days; dates before collection remain empty.
Cumulative calls on shown dates
Waiting for statistics
Displayed range: — calls
Signing and verification
Shared trust capabilities for every application
PDFs and any watermark carriers are processed locally. The service receives only necessary digests, commitments, signatures and minimal metadata; it does not read the original PDF.
Methodology and data sources Independent API processing records
Statistics come from signing and verification records in the independent YunyuTrace API. Legacy records and operations not reported through this API are excluded. Signatures count successfully registered signatures. Verifications count completed, recorded verification calls, including mismatched results. Timestamp jobs, page-proof registration, revocations and version statements are excluded from these two call counts; local benchmark runs are not production activity.
File counts total the input files in each operation. Processing volume totals input file sizes reported by integrated projects, not traffic uploaded to YunyuTrace servers. A new independent operation on the same file is counted again; retries of the same idempotent request are not counted twice.
The map groups business calls by the province associated with the source IP; it does not count unique visitors. EdgeOne sources are identified through the site’s origin-facing network ranges and resolved with an offline IP database. Today’s IP count resets at 00:00 UTC and is deduplicated within each project. The same IP used across projects is counted separately, so it is not a count of people. Public page views and automatic refreshes do not increase business call counts.
The page refreshes every 60 seconds and API aggregates are cached for 30 seconds. Unavailable data is not replaced with zeros. Locations that cannot be resolved are classified as unknown.
YunyuTrace CapabilitiesCurrent YunyuTrace capabilities
A file trust service for business systems. A signed PDF can travel with an external proof bundle; recipients can check the file digest, platform signatures, available time evidence, fixed-render page proof and online status separately.
One PDF, four evidence steps
Each stage states exactly what it establishes, from local finalization to recipient verification.
- 01Finalize locallyHash the final PDF after all changes
- 02Register and signThe platform signs identity and separate evidence
- 03Deliver externallyGive the PDF and proof bundle to the recipient
- 04Check separatelyVerify bytes and signatures locally; check current status online
01 / IDENTITYFile identity and digestBind final file bytes
Register the final PDF’s SHA-256 after all PDF writes are complete. A record locator or watermark does not establish integrity without checking the actual file bytes.
02 / SIGNATUREPlatform signaturesProtect the registered node
Ed25519 protects the original YYC/1 registration node. Additive evidence has separate signed domains; historical signatures and public keys remain verifiable.
03 / OFFLINE PROOFIndependent offline verificationCheck locally as recipient
Deliver the PDF with an external proof bundle. Recipients can verify the file digest, original node and new evidence with a pretrusted or explicitly configured public key, without platform access.
04 / SIGNATURE TIMESignature time evidenceSeparate platform and TSA time
An RFC 3161 token can bind the node digest, signature, algorithm and key identifier. Platform registration time and verified TSA time are shown separately; pending or failed requests are not reported as granted.
05 / PAGE PROOFFixed-render page proofCheck fixed-render images
Local SDK rendering commits each page, its order and size to a signed root bound to the final PDF digest. Recipients can check the whole document or a witnessed page under the specified render rule.
06 / WATERMARKWatermark carrier semanticsSeparate markers from visual signals
Local watermarks can help locate identity. A PDF structural marker is reported separately from successful visual-signal decoding and never replaces digest and signature checks.
07 / STATUSRevocation and current statusCheck revocation and replacement
Original records are retained. An exported proof contains status at export; current revocation or replacement must be checked online with a recent signed status statement.
08 / VERSIONAuthorized version relationshipsAuthorize with a management key
A local management key can authorize a signed link between earlier and later PDF identities. The link records the holder’s declared operation; it does not prove that only that edit occurred.
09 / PRIVACYLocal file processingKeep the source PDF local
PDF parsing, rendering and page comparison run locally. The service does not receive the source PDF, page images or extracted text.
10 / INTEGRATIONVersioned API and SDKIntegrate with existing systems
Applications use project authorization for registration and a separate holder credential for reading and verification. Possessing a PDF or proof bundle does not grant management authority.
A complete delivery workflow within your application
Suitable for websites, apps and internal platforms, with clear responsibilities for local file processing, business authorization and trust services to support independent maintenance and continued expansion.
- Process files locally
- Authorize in the application backend
- Register and sign
- Deliver files and proofs
Evidence is reported by scope: signature validity, exact file integrity, page rendering, verified TSA time and current online status. A selected-page match covers only that page. The service does not independently inspect client-submitted pages. These checks do not establish the truth of the content, the real-world identity of its author or the authenticity of a seal. Older files without new evidence remain verifiable under their original protocol.