VAT Evidence Telemetry — Provider Privacy Notice

Last updated: July 30, 2026

This notice describes the territorial-evidence telemetry Digital Frontier operates on its Akash provider infrastructure. It is separate from, and additional to, the site Privacy Policy.

Maintenance. This page is the authoritative published text. Its retention periods must be kept in step with retention_policy.yaml in the vat-evidence-pipeline repository, which is the single source of truth for retention. That synchronisation is currently manual: if you change one, change the other in the same pull request.

Controller Identity

The controller of the VAT evidence telemetry described here is:

Digital Frontier Unipessoal LDA
Registered in Cascais, Portugal
Data protection contact: Jonathan Borduas — dpo@digitalfrontier.so

Digital Frontier Unipessoal LDA determines both the purpose of this processing (territorial VAT evidence for EU revenue classification) and the means (capture, HMAC signing, GeoIP enrichment, classification, and retention). It is the same controller named in our Privacy Policy, Terms of Service, and Acceptable Use Policy, and it is the taxable person on whom the VAT record-keeping obligation described below falls.

Categories of Data Collected

This pipeline captures the data necessary to assign territorial evidence for EU VAT classification of revenue earned through Native Rail Akash provider deployments:

Control-plane telemetry:

Source IP address (retained in raw form for the window declared below, then replaced by its HMAC)
Owner wallet address claimed by the tenant
Owner wallet address verified by the protocol
Deployment sequence number (DSEQ), group sequence number (GSEQ), and order sequence number (OSEQ)
Control-plane route, route class, and HTTP method
Response status code
Authentication state of the request
Event timestamp and event type
Provider identity, provider wallet, and upstream version metadata

Derived enrichment fields:

Country code (derived from GeoIP lookup on source IP)
Autonomous System Number (ASN) and organisation name (derived from GeoIP/ASN lookup)
Flags for hosting provider, CI/CD provider, VPN/proxy, and Tor exit node (derived from GeoIP enrichment)
Confidence values and classification bucket (derived via the classification engine)
Observation state tracking (derived during classification)

Operational metadata:

HMAC key identifier and source-IP provenance
GeoIP database version and bundle integrity hash
Capture schema version
Provider fork version and commit
Clock-confidence flag

What we do NOT capture:

Any application workload content, payload, or end-user traffic
Deployment container images or configuration
Any data from inside a lease (only control-plane / operator interactions: manifest submit, lease shell, lease logs, lease status)
Personal identifying information beyond the pseudonymous wallet address and source IP

Purpose of Collection

Primary purpose: Production of territorial evidence for EU VAT classification of Native Rail Akash provider revenue. The Akash protocol does not natively expose civil identity, tax residency, or billing address, so we record operational signals (source IP, verified wallet, control-plane interactions) to support a documented, good-faith territorial allocation methodology compliant with EU VAT directives.

Secondary purpose: Operational security and system observability — understanding provider health, deployment patterns, and request patterns to detect anomalies and guide infrastructure decisions.

Legal / Tax Evidence Purpose

Territorial evidence (long-term retention): GDPR Art.6(1)(c) — legal obligation. The obligation relied on is Portuguese VAT record-keeping (Código do IVA Art.52 and Decreto-Lei 28/2019 Art.19), which covers VAT records and their supporting documents. Territorial evidence is a supporting document for those records. Derived metadata (country, ASN, classification bucket) are retained alongside the associated wallet address and deployment sequence for the period stated in the retention table below, to support tax evidence, audit, and dispute resolution.

The exact period that obligation requires is under review with our advisers. Should it prove longer than the period in the table, we will extend retention and update this notice rather than quietly leave the two out of step.

Source IP (bounded raw window): GDPR Art.6(1)(f) — legitimate interests in producing defensible territorial evidence while minimising direct identification. The raw IP window is far shorter than the evidence period and is declared in the retention section below.

Evidence, not a residency determination: the classification bucket we assign is territorial evidence for VAT allocation. It is not a determination of your tax residency or legal identity — the same disclaimer the audit packet carries.

The lawful basis claimed for each individual field, and the GDPR article it is claimed under, are declared per field in the Retention Schedule and HMAC Key Lifecycle table below.

Security Purpose

Security monitoring and operational observability: GDPR Art.6(1)(f) — legitimate interests of the controller in protecting the system from abuse and understanding its operation.

This is a secondary use of data already captured for the territorial-evidence purpose; it does not cause any additional field to be collected, and it does not extend any retention period beyond the ones declared below. Where a field's primary basis is the Art.6(1)(c) legal obligation, that basis governs how long it is kept.

Source IPs are keyed with HMAC-SHA256 under a rotating secret held in Vault. Plain SHA256 of an IP is never used, because a 32-bit address space makes it reversible by brute force in hours.

Raw IP Retention and HMAC Replacement

Why we capture source IP: It is the strongest operational signal available to infer a data subject's territory. The Akash protocol provides no billing address, residency proof, or civil identity, so the request's origin IP is the most reliable proxy for territorial allocation.

How we protect it: The source IP is immediately HMAC-SHA256 signed with a monthly-rotating secret held in Vault. Plain SHA256 of an IP is never used because it is reversible by brute force in hours.

Raw IP retention window: the raw source IP is stored only for the short window declared in the retention table below. After that window the scheduled job nulls it, and only the HMAC-derived value survives. We are working towards not writing the raw address at all — using it in memory for the HMAC and the country lookup and discarding it before the record is written — but that is not yet how the system behaves, and we would rather say so than imply it.

After the raw IP window: Once the raw source IP is deleted, the derived metadata (country, ASN, hosting/CI flags) depend on the persisted ASN rather than on live GeoIP lookups, so historical territorial classification can be re-derived without retaining the raw IP indefinitely.

Derived Metadata Retention

Derived metadata (country code, ASN, classification bucket) are retained for the same period as the corresponding HMAC and wallet addresses, declared in the retention section below, because they are directly linked to the verified wallet and deployment and they support VAT evidence, audit, and dispute resolution.

What the HMAC digest can and cannot do. It is keyed per key version, so the same address produces a different digest after each key rotation — it cannot be used to follow anyone across rotations. Once the key is destroyed the digest cannot be reversed to an address at all.

It is nonetheless retained for the same period as the rest of the record, as the table below shows, because it identifies which rows belong together across rotations. It plays no part in the VAT determination itself, which rests on the country and network operator already recorded. Whether it needs to be kept for the full period once its key is destroyed is a question we are actively reviewing.

This does not make the record anonymous. The same row still contains the verified wallet address and deployment sequence for the full evidence period. A wallet address is an identifier, so these records remain pseudonymous personal data — and remain subject to this notice and to your rights under the GDPR — for as long as they are retained. We do not claim that destroying the HMAC key anonymises them.

Retention Schedule and HMAC Key Lifecycle

The values in this section must match retention_policy.yaml in the vat-evidence-pipeline repository, which is the single source of truth for retention. Keeping them in step is currently a manual step in review, not an automated check.

The values in this section are taken from retention_policy.yaml in the vat-evidence-pipeline repository, which is the single source of truth for retention.

Field Name	Table	Retention	Deletion Method	Lawful Basis	GDPR Article
`source_ip`	`vat_events`	30 days	column_null_on_partition_detach	legitimate_interests	GDPR Art.6(1)(f)
`source_ip_hmac`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c) + national VAT law
`owner_wallet_claimed`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c) + national VAT law
`owner_wallet_verified`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c) + national VAT law
`dseq`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c) + national VAT law
`gseq`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c) + national VAT law
`oseq`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c) + national VAT law
`geo_country_code`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c)
`asn`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c)
`asn_org`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c)
`is_hosting_provider`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c)
`is_ci_cd_provider`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c)
`is_vpn_or_proxy`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c)
`is_tor_exit`	`vat_events`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c)
`classification_bucket`	`dseq_summary`	2555 days	partition_detach_then_drop	legal_obligation	GDPR Art.6(1)(c) + national VAT law

Every other column is covered too. The table names the fields that most directly identify or locate a data subject, and the shorter raw-IP window. The remaining columns of an event record — route, route class, HTTP method, response status, authentication state, event type and timestamp, provider and upstream version metadata, capture schema version, GeoIP bundle version and hash, clock-confidence flag, and confidence values — sit in the same row as the fields above. They are retained for the same period and destroyed with it. No event data is kept beyond that period.

How deletion actually works

The events table is partitioned by day. A scheduled job runs daily and does two things: it nulls the raw source IP on partitions older than the raw-IP window, and it detaches and drops partitions past the full retention period. Deletion is therefore a real, scheduled operation, not a promise.

Two limits worth stating plainly rather than letting you assume otherwise:

Deletion is age-based, not per-person. We cannot currently remove one individual's records on request ahead of the schedule. See Right to erasure below for what that means for you in practice.
Backups are separate. Removing a row from the live database does not by itself remove it from a backup taken earlier. We are reviewing backup retention so that it does not outlast the periods above.

HMAC key rotation: Every 30 days the key used to HMAC source IPs is rotated. Historical digests computed with a prior key remain readable but are not practically reversible without that key.

HMAC key destruction: After 120 days a retired key is destroyed via a signed destruction record, after which digests made with it cannot be reversed at all.

Recipients and International Transfers

Categories of recipients (GDPR Art.13(1)(e)). We do not sell, rent, or share this telemetry with advertisers, data brokers, or analytics providers. It is disclosed only to:

Our infrastructure provider, which hosts the Kubernetes cluster and database that store these records and acts as our processor.
Our own personnel with an operational or compliance need to access it.
Tax authorities, auditors, and professional advisers, where disclosure is required to satisfy the VAT obligation this evidence exists to support, or to defend an assessment.
Law enforcement or a court, where we are legally compelled — for example under a Portuguese Cybercrime Law (Law 109/2009) preservation or disclosure order.

GeoIP enrichment sends nothing to a third party. Country and ASN are derived by querying MaxMind GeoLite2 database files that we download, verify, and query locally. Your IP address is never transmitted to MaxMind or to any other geolocation service for lookup.

International transfers (GDPR Art.13(1)(f)). All processing takes place within the European Economic Area. We do not transfer this telemetry outside the EEA.

Specifically: telemetry is captured on the Akash provider infrastructure you actually connect to, which is in Bulgaria (Sofia), Portugal (Lisbon) or Finland (Helsinki) depending on the provider, and is then stored centrally in Finland. Backups of that central store are held in EEA object storage.

If any of that ever changes, this notice will be updated before the transfer begins and an appropriate Article 46 safeguard will be put in place.

Automated Processing

The classification engine assigns a territorial classification bucket to a deployment automatically, from the signals described above.

This is not a decision producing legal effects concerning you or similarly significantly affecting you within the meaning of GDPR Art.22: it determines how we classify our own revenue for VAT purposes. It does not determine your tax residency, does not change your access to the service, your pricing, or your standing as a customer, and no automated refusal or restriction follows from it.

If you believe a bucket assigned to your deployment is wrong, you can ask us to correct it — see Right to rectification below. Corrections are made by a person, and recorded as traceable audit events.

Data Subject Rights

Right to access (GDPR Art.15): You may request access to the personal data we hold about you. Because this pipeline holds pseudonymous data (wallet addresses and IP-derived values), a request must be accompanied by cryptographic proof of control of the wallet address, so that we can identify your records and avoid disclosing someone else's.

Right to rectification (GDPR Art.16): If you believe the classification bucket assigned to your deployments is incorrect, you may request correction. Corrections are recorded as audit events and are traceable.

Right to erasure (GDPR Art.17): You may request erasure. For the fields held under the Art.6(1)(c) legal obligation, GDPR Art.17(3)(b) allows us to decline while the VAT retention period stated in the table above runs, and we will normally do so — deleting mid-period would breach the tax obligation. Where we decline, we will tell you why and which obligation we are relying on, and when the period ends for your records.

The raw source IP is different: it is held under legitimate interests rather than the tax obligation, so it is within scope of erasure and objection.

Here is exactly what happens today. We would rather you knew the limit than assumed a stronger one:

We record your request and confirm receipt in writing.
We assess it, and where it succeeds we stop using your data for any new purpose.
We cannot yet remove one person's records ahead of the schedule. Deletion is age-based: a scheduled job acts on everyone's expired data together. We will tell you the date your records fall out of the retention window.
We are building the ability to restrict and delete an individual's records on request. Until that exists we will not tell you your data has been placed beyond use, because it would not be true.

Right to restriction (GDPR Art.18): You may ask us to restrict processing — for example while a rectification request or an objection is being considered.

Right to data portability (GDPR Art.20): Article 20 applies only to processing carried out on the basis of consent or of a contract. This telemetry is processed under a legal obligation (Art.6(1)(c)) and legitimate interests (Art.6(1)(f)), so a portability right does not arise here and we do not claim to offer one. You can still obtain a copy of your data under the right of access above, and we will provide it in a structured, machine-readable format on request.

Right to object (GDPR Art.21): You may object at any time to processing based on legitimate interests — here, the raw source IP and the security-monitoring use. We will stop unless we can show compelling legitimate grounds that override your interests. Where an objection to the raw source IP succeeds, we stop using that data for any new purpose and confirm this in writing. The same limit as above applies: removal happens through the scheduled process, not on demand, and we will tell you when that falls due. We will not describe your data as restricted while our systems can still reach it. The right to object does not extend to processing we carry out to satisfy the VAT legal obligation.

How to exercise these rights: contact dpo@digitalfrontier.so. We will respond within one month of receipt, as required by GDPR Art.12(3), and will tell you if we need to extend that period.

Right to lodge a complaint: If you believe this processing violates your rights, you may lodge a complaint with your national data protection authority. In Portugal, that is the Comissão Nacional de Proteção de Dados (CNPD), www.cnpd.pt.

Contact Details

Data protection contact: Jonathan Borduas — dpo@digitalfrontier.so. Send access, rectification, erasure, restriction, and objection requests to that address.

Postal: Digital Frontier Unipessoal LDA, Cascais, Portugal.

Supervisory authority: see Right to lodge a complaint under Data Subject Rights.

Where this notice is published: on the Digital Frontier website at https://digitalfrontier.so/legal/vat-telemetry-privacy-notice. Each Digital Frontier Akash provider references this URL from its on-chain provider record so that tenants who never use the web console can still find it.

Important Notes

Territorial evidence, not identity proof: The classification bucket assigned to your deployment is treated as territorial evidence for VAT allocation purposes only. It is not definitive proof of your tax residency or legal identity. Any such determination requires additional evidence and formal tax compliance review.

No workload inspection: We never inspect your application code, container images, or end-user-facing traffic. We observe only control-plane and operator interactions — manifest submission, lease shell, lease logs, and lease status.

Immutable audit trail: HMAC key rotation and destruction are logged and cryptographically verified — each key destruction carries a signed attestation. The daily signed manifest floor provides a tamper-proof record of every event batch, allowing independent auditors to verify the integrity of the evidence set. Equivalent verification of the retention and deletion runs arrives with the enforcement described above; we do not claim it before then.

Changes to this notice: if we change what we collect, why, or how long we keep it, we will update this page and its "last updated" date before the change takes effect.