2026 SingLinkVPN No-Logs Audit Evidence and Workpaper Status Report

2026 SingLinkVPN No-Logs Audit Evidence and Workpaper Status Report

Independent No-Logs Policy Verification Report

Service reviewed

SingLinkVPN

Audit organization

VPNTestor Platform

Audit team

Openscore VPN

Lead auditor

James Robert Smith

Nature of audit

Independent third-party technical verification of the no-logs policy

Audit method

Read-only inspection of the production environment

Audit reference date

July 29, 2026

Report version

1.0

Signature status

James Robert Smith has not signed; this is not an issued final third-party opinion

Overall conclusion

Integrity of two operator evidence packages passed; the central control plane is partially supported, with open findings and pending audit procedures

1. Executive summary

As of July 29, 2026, SingLinkVPN submitted sanitized central-control-plane evidence, aggregate statistics, and a set of audit workpapers to VPNTestor Platform and Openscore VPN. The complete workpaper status register shows that some central-control-plane items have operator verification material, while the engagement letter, independence declaration, read-only authorization record, controlled tests, node scans, third-party and backup reviews, and final signature remain incomplete.

During this audit:

• No production data was modified;

• No node addresses were exported;

• No server keys were exported;

• No user account data was copied;

• No production database was exported;

• No internal interface, token, or security configuration was disclosed.

The integrity-protected central traffic-accounting schema contains no fields for persistently recording the following destination activity:

• Websites visited by users;

• Destination domains;

• Full URLs;

• DNS query records;

• Browsing content;

• Network communication content;

• Original connection IP addresses;

• The specific VPN node used by a user;

• The start and end time of an individual connection;

• Session records capable of associating a user account with specific network activity.

SingLinkVPN processes a limited amount of account and metering data required to provide the service. This includes cumulative traffic values, daily traffic totals, temporary online-device status, virtual email addresses, order numbers, customer-support information, and remote-diagnostic data voluntarily submitted by users.

This data does not contain websites, domains, URLs, DNS queries, or communication content accessed by users. The audit also found no evidence that it is used to create browsing histories or network-activity profiles.

The limited conclusion supported by the currently submitted material is:

The operator-signed material supports that no activity-destination fields were found in the central traffic-accounting path and that limited data-minimization and retention controls exist. A system-wide unqualified no-logs opinion cannot be issued until the open findings, controlled tests, 28 resolved endpoints, third parties, backups, and access controls have been completed.

Public evidence package and integrity verification

On July 29, 2026, the audited party separately submitted version 1.0 of a public cryptographic evidence package. VPNTestor verified the integrity of the submitted files. “The files have not changed since signing” must, however, remain distinct from “the underlying facts have been independently reproduced by a third party.”

• Download the public evidence ZIP

• Download the ZIP SHA-256 file

• Download the Ed25519 signature

• Download the Ed25519 public key

The signing key is the audited party’s evidence-signing key, not an audit-signing key belonging to VPNTestor or Openscore VPN. A valid signature proves only that the files have not changed since signing; it does not independently establish the truth of the operator’s statements.

The package publicly supports four types of material: minimization of fields in the central traffic-accounting tables, the configured two-month retention period and observed date range for traffic aggregates, short application-level TTLs for online state, and a sanitized aggregate node inventory. Source-code hashes become probative only after an auditor privately obtains the corresponding source files and recalculates the hashes.

The public package alone does not prove the absence of local access logs on every VPN node or the deletion state of CDN, cloud-platform, Redis-persistence, database-backup, support-ticket, or remote-diagnostic data. Those conclusions require independent read-only reproduction, runtime records, or documented sampling and must not be inferred from the operator’s signature.

Complete audit workpapers and signature status

The audited party subsequently submitted a repackaged v1.0 audit-workpaper archive. VPNTestor verified the ZIP, the manifest covering 52 files, the outer checksum-file signature, and the internal manifest signature. Both signatures were created with the audited party’s evidence-signing key and establish integrity only.

• Download the complete audit-workpaper ZIP

• Download the workpaper ZIP SHA-256

• Download the workpaper integrity signature

• View the signature-page template

• View the signing request and instructions for James Robert Smith

The workpaper status register also discloses that controlled unique-domain, original-IP, DNS, and connection-metadata tests have not been performed; the 28 resolved endpoints have not completed endpoint-by-endpoint log review; SingChat deletion, 14-day diagnostic deletion, and backup retention have open findings; and cloud, CDN, DNS, monitoring, RBAC, MFA, export permissions, and administrator-operation records remain pending.

The signature page merely pre-fills James Robert Smith as the intended signer and is marked “unsigned.” James must personally sign the final frozen report using a certificate or private key under his control before a third-party independent signing relationship exists. The current operator integrity signature must not be represented as James’s signature, an audit-organization signature, or a final audit opinion.

2. Audit independence statement

This page records the intended independent audit scope, submitted evidence, and current work status. The independence-declaration template remains pending completion and signature by the auditor, so this page is not currently an issued independent third-party final opinion.

The auditors are not members of SingLinkVPN’s internal product, development, operations, or management teams. They do not participate in the audited system’s day-to-day operation, data processing, node maintenance, or privacy-policy development.

For this inspection, the auditors received only the restricted read-only access required to complete the audit and followed these principles:

• Do not modify production data;

• Do not obtain production keys;

• Do not export node addresses;

• Do not copy the user database;

• Do not access user communication content;

• Do not perform destructive testing against the production service;

• Do not publish configurations that could affect node security.

This is an independent third-party technical verification report. It is not a SOC 2 report, an ISO certification, a financial assurance report, or a government compliance certification.

The audit method referenced general principles for privacy-information management and log governance. ISO/IEC 27701:2025 provides requirements and guidance for privacy information management systems, while NIST SP 800-92 addresses methods for log generation, protection, review, and retention. Referencing these frameworks does not mean that SingLinkVPN or the audit organization is certified under them.

3. Audit definition of “no logs”

In this report, “no logs” means:

SingLinkVPN does not record, store, or persist data that reveals websites visited by a user, destination domains, full URLs, DNS queries, browsing content, network communication content, original IP addresses, or specific connection activity.

“No logs” does not mean that a VPN service processes no data at all.

The system may process limited service data to provide subscriptions, traffic metering, device-count limits, order lookup, customer support, and remote diagnostics requested by a user.

This report divides data into three categories.

3.1 User activity data that must not be recorded

SingLinkVPN’s no-logs policy prohibits persistent storage of:

• Websites visited;

• Destination domains;

• Full URLs;

• Webpage paths;

• DNS queries;

• Browsing content;

• Communication content;

• Application network content;

• Original IP addresses;

• Long-term mappings between VPN-assigned IP addresses and accounts;

• Specific nodes used;

• Start and end times of individual connections;

• Connection-duration history;

• Session mappings that identify user activity.

3.2 Limited service data

To provide normal service, the system processes:

• Cumulative user upload traffic;

• Cumulative user download traffic;

• Daily upload and download traffic;

• Last-used status;

• Temporary online-device status;

• Virtual email addresses used for registration;

• Order numbers;

• Customer-support tickets;

• SingChat conversations;

• Remote-diagnostic information voluntarily submitted by users.

This data does not include a user’s specific destinations or browsing content.

3.3 Temporary transport state

While providing real-time data forwarding, VPN nodes temporarily process the following in memory:

• Current connection state;

• Temporary sessions required for data forwarding;

• Temporary network buffers;

• Real-time routing state;

• Protocol handshake state.

These states are used only to complete the current connection and transmission. They are not written to persistent activity logs and are automatically released after disconnection.

4. Audit scope

4.1 Network and node scope

As of July 29, 2026, the inspection identified:

These figures come from a sanitized aggregate snapshot generated and signed by the audited party at 2026-07-29T05:06:41Z. VPNTestor verified file integrity. The aggregate queries must still be rerun in an independent read-only session before they can be described as independently reproduced results.

Logical records, visible configurations, host aliases, and resolved endpoints are different statistical dimensions and must not be added together as a total node count. The value 105 means “visible logical configurations.” It must not be described as 105 physical servers, 105 unique IP addresses, or 105 nodes whose local logging has been audited.

This aggregate inventory does not establish node-local logging behavior. The report also provides no financial or legal assurance regarding data-center ownership, legal ownership of servers, or registration ownership of IP addresses.

4.2 System scope

The audit scope included:

• Central account administration;

• User data-reporting interfaces;

• Node-configuration systems;

• Protocol-configuration systems;

• User traffic-metering systems;

• Online-device limit systems;

• Order and after-sales lookup systems;

• The SingChat customer-support system;

• Remote-diagnostic logging systems;

• Local logging policies on VPN nodes;

• DNS query processing;

• Cloud-service and CDN logging configurations;

• Data query and export capabilities;

• Automatic cleanup and destruction rules.

5. Audit methodology

The audit team primarily used the following non-destructive technical methods.

5.1 Data-structure inspection

The team inspected fields in the central administration system and related databases to determine whether they contained:

• Domain fields;

• URL fields;

• DNS query fields;

• Original IP fields;

• Node-usage history fields;

• Connection-time history fields;

• Communication-content fields;

• Browsing-history fields.

5.2 Reporting-interface inspection

The team inspected the data types submitted by clients and nodes to the central administration system to determine whether reporting interfaces included:

• User destinations;

• DNS queries;

• Original IP addresses;

• URLs;

• Network content;

• Node-access history.

5.3 Configuration inspection

The team inspected:

• Node logging configurations;

• Application logging configurations;

• DNS logging configurations;

• Cloud-service logging configurations;

• CDN access-log configurations;

• Data-retention configurations;

• Automatic cleanup jobs;

• Administrative export functions.

5.4 Data sampling

Without exporting the production database, the team performed read-only sampling of existing data to confirm that the data actually stored by the system was consistent with its database fields and documented policies.

5.5 Deletion-rule inspection

The team examined automatic deletion and cleanup rules for different categories of limited service data, including:

• Daily traffic records;

• Customer-support conversations;

• Remote-diagnostic data;

• Virtual email and order records;

• Temporary device state;

• Temporary node transport state.

6. Overall audit results

This table describes what the newly submitted public package can support. It does not automatically elevate an operator signature into independent third-party verification. Where earlier wording used a broad “Passed,” this more precise evidence status and its limitations control.

7. User access-activity audit

The audit team inspected the central administration data-reporting interfaces and related data structures.

Within the inspected scope, the following fields were not found:

• Visited domains;

• Destination websites;

• Full URLs;

• Webpage paths;

• HTTP request content;

• Browsing content;

• Communication bodies;

• Application network content;

• Search content.

The audit team also found no data structure capable of establishing this relationship:

``text User account → a particular time → a particular node → a particular domain or website ``

The existing central administration data therefore cannot be used to reconstruct which websites or network services a particular user accessed.

Public-evidence status: The central traffic tables contain no destination-domain, DNS, URL, SNI, content, path, host, or IP fields. This result comes from an operator-signed snapshot and still requires the auditor to rerun the query.

8. Original IP and connection-log audit

The audit found no evidence that SingLinkVPN’s central administration persistently stores the original IP address used before a user connects to the VPN.

It also found no per-connection history containing:

• Original IP address;

• VPN-assigned IP address;

• Node used;

• Connection start time;

• Connection end time;

• Connection duration;

• Session ID;

• Source port;

• Destination port;

• Mapping between an original IP address and an account.

The system contains a “last used” status field, but it is used for account and service-state management. It does not include the corresponding destination, node, original IP address, or connection details.

This field alone cannot be used to reconstruct a user’s browsing activity.

Public-evidence status: The public package supports only the absence of an IP field in the central traffic-accounting tables. It does not prove that login, device, proxy, node, or other subsystems process no IP metadata. Further verification is required.

9. DNS query-log audit

The inspection found no evidence that SingLinkVPN writes users’ DNS queries to the central administration system or any other persistent activity log.

No evidence was found of storage for:

• Domains queried by users;

• DNS request-time history;

• Mappings between DNS results and accounts;

• Mappings between DNS queries and original IP addresses;

• Mappings between DNS queries and specific nodes.

DNS resolution is used only to complete real-time network connections and does not create a database of user DNS history.

Public-evidence status: The public package supports only the absence of a DNS field in two central traffic-accounting tables. It does not establish the absence of DNS logs in node resolvers or other subsystems. Further verification is required.

10. User traffic-statistics audit

SingLinkVPN stores the following per user:

• Cumulative upload traffic;

• Cumulative download traffic;

• Last-used status;

• Daily total uploads;

• Daily total downloads.

This data is used to:

• Calculate free traffic allowances;

• Enforce plan traffic limits;

• Display a user’s current usage;

• Prevent reuse of traffic allowances;

• Handle user traffic inquiries.

Traffic statistics do not contain:

• The website to which traffic was sent;

• The domain accessed;

• The URL used;

• Packet content;

• User browsing content;

• DNS queries;

• Specific application names.

The system can therefore determine how much traffic an account used, but traffic statistics cannot establish what content the user accessed.

Daily traffic retention

Daily upload and download totals are stored per user. The code and production cleanup rules are configured to delete them automatically after approximately two months.

This is daily aggregated metering data, not a per-connection log.

Public-evidence status: The signed package supports the configured two-month retention window, daily schedule, and observed date range. The auditor should still inspect the scheduler and recent execution records.

11. Online-device status audit

SingLinkVPN temporarily processes a user’s current online-device status to:

• Enforce device-count limits;

• Prevent use beyond the device entitlement of a plan;

• Determine whether a current device remains in a valid session.

The signed evidence package states that node-reported online IP state uses a 120-second application cache, the per-user online connection map uses a 300-second cache, and stale node components are pruned after 100 seconds.

These TTLs support the statement that the application treats this information as short-lived state. They do not independently prove the absence of copies in Redis RDB/AOF, infrastructure snapshots, upstream proxies, or node-local systems.

Public-evidence status: Application-level TTLs are supported by operator-signed material; Redis persistence and backups still require independent review.

12. Virtual email and order-number audit

SingLinkVPN’s account system processes:

• Virtual email addresses used for registration;

• Order numbers;

• Plan and subscription status;

• The minimum records required for after-sales inquiries.

This data is used only to:

• Look up subscriptions;

• Verify orders;

• Recover accounts;

• Resolve payment issues;

• Provide after-sales support.

The audited party describes virtual email addresses and order numbers as limited service data required for subscriptions and after-sales support, rather than VPN browsing-activity logs.

The newly submitted public package expressly excludes login, device, order, payment, and fraud-prevention metadata and contains no execution record for a three-month cleanup job.

Public-evidence status: Not verified by this package. The three-month cleanup cycle and permanent-deletion result require independent inspection of database fields, cleanup jobs, and execution records.

13. Customer-support ticket and SingChat audit

Customer-support tickets and SingChat may contain information voluntarily entered by users, including:

• Problem descriptions;

• Error information;

• Device information;

• Screenshots;

• Correspondence.

This is customer-support information voluntarily submitted by a user, not browsing logs automatically collected by the VPN.

The audited party previously stated that SingChat and related support systems have a post-conversation deletion mechanism and that completed conversations are not subsequently used for:

• User profiling;

• Advertising analysis;

• Browsing-history analysis;

• Network-activity tracking;

• Long-term archiving of customer-support content.

The latest workpapers classify this as a high-severity open finding: no production cleanup-job evidence currently establishes immediate post-session deletion or fixed-period automatic deletion, and persistent support tickets and messages were observed.

Current status: OPEN_FINDING. The report must not claim immediate post-session deletion until an auditable cleanup job, failure alerts, and sample retesting are complete.

14. Remote-diagnostic log audit

Remote diagnostics are used only when a user voluntarily requests after-sales support or technical assistance.

Their purposes include:

• Analyzing connection failures;

• Inspecting client status;

• Identifying node-configuration issues;

• Improving troubleshooting accuracy.

The audited party states that the remote-diagnostic project is open source and makes the following policy statements:

• Does not run as continuous background monitoring by default;

• Is generated only after a user voluntarily consents or submits it;

• Is not used to create browsing-activity records;

• Is not used for advertising or user profiling;

• Is retained for no more than 14 days;

• Is automatically cleaned and destroyed when the retention period expires.

Public source code helps external researchers inspect the design, but the complete workpapers confirm that a remote-diagnostic record table exists and no enabled scheduled job or verifiable execution record corresponding to “automatic deletion after 14 days” was found.

Current status: OPEN_FINDING. The diagnostic function and records are confirmed; enforcement of the 14-day retention period is not.

15. Local VPN-node logging audit

A strict no-activity-logs policy requires VPN nodes not to persistently store:

• Websites visited by users;

• Destination domains;

• Full URLs;

• DNS queries;

• Original IP addresses;

• User communication content;

• Node-usage history;

• Session mappings;

• Packet content;

• Connection logs capable of identifying browsing activity.

The audited party states that nodes process only the temporary state required for real-time transmission in memory, including:

• Current protocol sessions;

• Data-forwarding buffers;

• Temporary routes;

• Network-connection state;

• Handshake state.

The audited party’s technical statement is:

SingLinkVPN nodes maintain only the temporary in-memory session state required to provide real-time forwarding. They do not write user destinations, DNS queries, communication content, or session mappings capable of identifying user network activity to persistent storage. When a connection ends, the related temporary state is automatically released.

This is different from deleting logs that were already recorded.

SingLinkVPN’s approach is:

Do not generate user activity logs in the first place, rather than record them and delete them later.

The public package provides only aggregate node inventory. It contains no inspection records for processes, systemd/journald, container logs, Nginx, DNS resolvers, or crash dumps on the 28 resolved endpoints.

Public-evidence status: Not verified by this package. All nodes must not be marked “Passed” until endpoint sampling or endpoint-by-endpoint review is completed.

16. Cloud-provider, CDN, and infrastructure-log audit

A no-activity-logs policy requires cloud platforms, CDNs, and infrastructure components not to create persistent records capable of identifying user VPN activity, including:

• Mappings between users’ original IP addresses and VPN accounts;

• Domains accessed by users;

• Full URLs;

• DNS queries;

• Node communication content;

• User browsing histories;

• VPN session-activity profiles.

Normal system-availability monitoring may include non-user-activity metrics such as CPU, memory, and disk utilization. Those metrics must be distinguished from metadata capable of identifying or reconstructing user network activity.

The public package contains no cloud-platform, CDN, upstream-proxy, or infrastructure logging configuration.

Public-evidence status: Not verified by this package. The relevant provider configurations, retention policies, and access permissions require independent inspection.

17. Database-backup audit

If the production database does not collect the following data, its routine database backups should not contain those fields:

• Websites;

• Domains;

• URLs;

• DNS queries;

• Original IP addresses;

• Browsing content;

• Connection histories;

That inference does not replace inspection of the backups themselves. Limited account and order data may still enter routine disaster-recovery backups and must comply with its applicable retention and deletion rules.

The public package does not cover database backups, Redis RDB/AOF, cloud snapshots, or off-site backups.

Public-evidence status: Not verified by this package. Backup scope, retention, recovery samples, and deletion propagation must be inspected.

18. Administrator access and export-permission audit

A strict no-activity-logs design requires the administration system to have no function to query or export:

• Websites visited by a particular user;

• DNS queries made by a particular user;

• Full URLs accessed by a particular user;

• The history of specific VPN nodes used by a particular user;

• A particular user’s original IP history;

• A particular user’s browsing content;

• A particular user’s communication content.

The audited party states that administrators and customer-support personnel can view only the limited account and order information required to provide the service and only within their authorized scope, and that limited account information may not be used for behavioral analysis.

The public package provides no system-wide administration permission matrix or inspection record for query pages and export functions.

Public-evidence status: Not verified by this package. A restricted audit account should be used to inspect role permissions, query capabilities, and export interfaces.

19. Data-retention and automatic-cleanup matrix

The following table summarizes operator policy statements and configurations visible in the submitted package. Only the two-month retention period for central traffic statistics and the application-level online-state TTLs are directly supported by this signed package; the remaining retention periods still require independent inspection of runtime records.

20. Summary of the no-logs technical design

SingLinkVPN’s no-logs design can be summarized in four principles.

20.1 Do not collect

For websites, domains, URLs, DNS queries, original IP addresses, and browsing content, the system does not create corresponding data fields or persistent reporting interfaces.

20.2 Process in memory

VPN nodes process only the temporary session state required for real-time forwarding in memory and automatically release it when a connection ends.

20.3 Minimize metering data

The traffic system stores only the aggregate values required to provide plan and allowance functions. It does not store traffic destinations or content.

20.4 Automatically destroy

Daily traffic, customer-support information, diagnostic information, and limited account information have separate cleanup cycles to prevent indefinite retention.

21. Audit conclusion

After reviewing the public evidence package and complete workpapers submitted on July 29, 2026, VPNTestor Platform separates “integrity verified,” “fact independently reproduced,” and “signed by the auditor”:

1. The ZIP SHA-256, the manifest covering all 9 public files, the outer ZIP signature, and the manifest signature all verified successfully.

2. The operator-signed sanitized schema shows two central traffic-accounting tables containing traffic counters and bookkeeping metadata; a scan for 15 activity-related column-name terms returned 0 matches.

3. Operator material shows a configured two-month retention period for central user and node traffic statistics, and the snapshot’s oldest and newest dates are consistent with that window.

4. Operator material shows a 120-second online-IP application-cache TTL and a 300-second per-user online-connection-map TTL.

5. Node inventory should be described as 206 logical records, 105 visible logical configurations, 33 host aliases, and 28 resolved endpoints. The value 105 is not a physical-server count.

6. Private source hashes can identify a version only after the auditor obtains the corresponding source and recalculates the hashes. The public cannot verify private-code logic from hashes alone.

7. The package does not support marking all node-local logging, CDN, cloud-platform, Redis-persistence, or database-backup controls as passed.

8. The package does not support marking deletion of support tickets, SingChat, remote diagnostics, login, device, order, payment, or fraud-prevention metadata as passed.

9. The audited party’s Ed25519 signature establishes integrity of the submitted material; it is not an independent audit signature from VPNTestor or Openscore VPN.

10. The complete workpaper ZIP, 52-file manifest, outer signature, and internal manifest signature all verified, but the workpapers themselves disclose multiple PENDING and OPEN_FINDING items.

11. James Robert Smith has not signed the final report; a pre-filled name is not an electronic or digital signature.

12. Central traffic-field minimization, retention configuration, application TTLs, and aggregate inventory have verifiable integrity support. Broader no-logs conclusions still require the independent procedures listed in this report and the auditor’s signature.

Final audit opinion

Evidence-package and workpaper integrity result: Passed. Some central-control-plane conclusions have operator-signed support, but high-severity open findings and multiple pending audit procedures remain, and James Robert Smith has not signed. The current status is therefore “audit work in progress; final independent opinion not issued,” not a passed system-wide no-logs audit.

22. Report limitations

This report applies only to:

• The audited systems identified in the report;

• The production-environment state as of July 29, 2026;

• The technical scope for which read-only access was provided;

• The services and node configurations identified in this report.

This report does not constitute:

• A permanent guarantee covering all future versions;

• Legal compliance advice;

• A SOC 2 assurance report;

• ISO certification;

• A financial audit;

• Legal assurance regarding data-center or IP ownership.

Verification should be repeated after a material change to the system, code, third-party suppliers, or data-processing practices.

This public evidence package was generated by the audited party. VPNTestor independently verified its hashes and digital signatures but has not, from this package alone, reproduced every private-source, production-query, 28-endpoint, Redis-persistence, backup, CDN, support, or diagnostic-cleanup claim.

23. Signature page

Audit organization: VPNTestor Platform Audit team: Openscore VPN Lead auditor: James Robert Smith Report type: Independent Third-Party Technical Verification Report of the No-Logs Policy Service reviewed: SingLinkVPN Report version: 1.0 Audit reference date: July 29, 2026 Audit conclusion: Not issued; evidence-package integrity passed, with substantive open findings and pending procedures

Signature status

Unsigned — awaiting James Robert Smith’s personal signature using his digital certificate or private key.

The pre-filled name is not a handwritten, electronic, or digital signature. After signing, the final frozen report, report SHA-256, verifiable signature, signing public key or certificate, fingerprint, signing date, and identity-verification statement should be published.