{"id":"7dff1c43-c35d-4689-b3d8-ba25351fc181","arxiv_id":"2506.16812","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"ZK-PoL protocols let vehicle owners prove subsidy eligibility or tax brackets from signed GPS trails without revealing the coordinates.","lead":"This paper designs zero-knowledge proof protocols that let a vehicle owner prove they drove enough kilometers inside a country, or prove a tax bill, without revealing where they drove. It builds a working prototype and measures runtime using Raspberry Pi and phone hardware.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Algorithm 4 computes area over the wrong third vertex, so the highway-tax triangle inclusion check is incorrect as printed.","rationale":"The reader's conditional verdict is reasonable: the physical tamper-evidence assumption is honestly flagged but is a deployment concern rather than an internal inconsistency. My stress-test identified a sharper, internal correctness issue in the printed protocol: Algorithm 4's first line uses the wrong third vertex, breaking the triangle-inclusion check on which Algorithm 3 relies. This is almost certainly a typo, but as written it undermines the completeness and soundness of the highway-tax protocol at the specification level. The appropriate disposition remains conditional acceptance, with the added condition that Algorithm 4 be corrected and the shipped implementation checked against the corrected formula. I did not find evidence of fabrication or circular reasoning; the topology, performance measurements, and proof sketch are plausible and internally consistent aside from this typo.","tokens_in":18258,"tokens_out":16925,"duration_ms":181943,"concrete_test":"Compile a minimal ZK-SecreC circuit implementing Algorithm 4 exactly as printed and run check_inside_triangle on a point clearly inside a reference triangle, for example the centroid of vertices (0,0), (10,0), (0,10). If the printed formula is used, the reconstruction assertion should fail for the honest barycentric coordinates; repeating the same test after changing line 1 to area_dbl((a1,b1),(a2,b2),(a3,b3)) should pass. This distinguishes a paper-only typo from an implementation-level error, and determines whether the reported highway-tax benchmark results remain valid.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The highway-tax protocol's completeness and soundness rest on Algorithm 4 (check_inside_triangle). Its first line sets A ← area_dbl((a1,b1),(a2,b2),(a2,b3)), using a2 as the x-coordinate of the third vertex and b3 as its y-coordinate; the intended third vertex is (a3,b3). As printed, the area A used in lines 3–6 is the doubled area of a different triangle, so the barycentric reconstruction x' = u·a1 + s·a2 + t·a3 (and the corresponding y-expression) does not correspond to the Prover's get_bcoords output computed from the actual triangle. An honest Prover's proof can therefore fail, and the geometric relation the circuit verifies is not 'point inside the given triangle'. Since Algorithm 3 depends on this helper, the central claim that the printed protocols let a Prover convince a Verifier of highway-tax compliance is not supported by the pseudocode as written. This appears to be a typo—the surrounding text and Appendix A use the correct vertices—but it is a concrete correctness defect that must be corrected before the protocol specification can be considered reliable.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper designs and evaluates zero-knowledge proof-of-location (ZK-PoL) protocols for two vehicle-related policies: proving eligibility for an EV subsidy (total driven distance and fraction of distance inside a set of circles) and proving highway-tax compliance (distance driven outside a set of triangles). The protocols are specified in Algorithms 1-5, implemented using the ZK-SecreC framework with MnC and emp-zk back-ends, and benchmarked on several devices. The paper also provides a UC-style security argument in Appendix B and discusses deployment assumptions, notably the tamper-evidence of the Witness device.","tokens_in":18417,"tokens_out":8136,"duration_ms":81988,"significance":"If the protocols are correct, the paper makes a useful practical contribution: it shows that standard ZKP techniques can be applied to location-based subsidy and taxation use cases with runtimes that are high but potentially acceptable for infrequent proofs. The strengths are the concrete prototype measurements in Table 1, the clear system model, and the explicit treatment of the Witness device trust anchor as a deployment limitation. The paper is also honest about relying on the correctness of underlying ZK back-ends and on the ZK-SecreC type system. The main weakness is that the printed pseudocode for the highway-tax helper contains a concrete correctness defect (Algorithm 4, line 1), which must be fixed before the protocol specification can be considered reliable.","major_comments":[{"comment":"The doubled area is computed as ∆area_dbl(Ja1K,Jb1K,Ja2K,Jb2K,Ja2K,Jb3K), i.e., with the third vertex given as (a2,b3) instead of the correct (a3,b3). This makes A inconsistent with the barycentric coordinates produced by get_bcoords and with the reconstruction x' = u·a1 + s·a2 + t·a3 and y' = u·b1 + s·b2 + t·b3 in lines 4-5. An honest Prover's proof can therefore fail (breaking completeness), and a malicious Prover may be able to satisfy the altered relation for points outside the intended triangle (undermining soundness of the protocol as printed). Because Algorithm 3's highway-tax claim depends on this helper, the central claim of the paper is not supported by the pseudocode as written. The surrounding text and Appendix A use the correct vertices, so this is very likely a typographical error, but it is load-bearing and must be corrected.","section":"Section 5.2, Algorithm 4, line 1"}],"minor_comments":[{"comment":"The text says \"for all circles j∈{0,...,ntraj}\" but the loop in Algorithm 1 ranges over n_circ; this appears to be a typo that should read j∈{1,...,n_circ}.","section":"Section 5.1, paragraph after Eq. (1)"},{"comment":"The pseudocode computes distances with a direct square root (e.g., Algorithm 1 line 9), while Section 5.3 describes an alternative formulation where the Prover supplies d_i and the circuit checks d_i^2 ≤ (dx^2+dy^2) < (d_i+1)^2. The relationship between these two presentations should be clarified, especially which version corresponds to the implementation used in Table 1.","section":"Section 5.3 vs. Algorithms 1 and 3"},{"comment":"The \"HW year\" rows are missing for the Raspberry Pi and phone provers; the caption or text should explain whether this is due to memory constraints, excessive runtime, or another technical reason.","section":"Table 1"},{"comment":"The variable Jb_piK is initialized for the first point and then updated at the end of each loop iteration; renaming it to something like Jprev_insideK would make the \"previous point inside a circle\" semantics clearer to readers.","section":"Section 5.1, Algorithm 1"},{"comment":"The security proof is explicitly a sketch and relies on the correctness of Algorithms 1-5; once the Algorithm 4 typo is fixed, the authors should also state the concrete cryptographic assumptions (e.g., unforgeability of the signature scheme, collision resistance of Poseidon) under which the UC argument is meant to hold.","section":"Appendix B"}],"recommendation":"major_revision","confidential_remarks":"The paper is a solid systems-oriented contribution, and the central protocols are plausible. The Algorithm 4 typo is concrete and load-bearing, but it appears to be a straightforward fix; the surrounding text and Appendix A are correct. I recommend major revision rather than rejection, with the expectation that the typo is corrected and the implementation is checked against the corrected specification. The paper's reliance on the Witness device as a trust anchor is clearly acknowledged and is a deployment concern rather than a technical flaw."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is a solid, honest feasibility study. The authors take two real policy problems — EV subsidy eligibility and highway-tax computation — and show how to express them as zero-knowledge statements in ZK-SecreC, with prototype measurements on realistic hardware. The main numbers are plausible: annual proofs on a PC around 36 minutes for the subsidy case and 59 for the highway tax case, with monthly proofs much smaller. That is not transformative, but it is a useful data point for anyone thinking about whether ZK-PoL can be deployed at government scale.\n\nWhat is actually new is the concrete encoding of geographic conditions — circles for territory, triangles for roads — and the measured performance of two backends (Diet Mac'n'Cheese and emp-zk). The cryptographic machinery is standard, but the applied contribution is real. The paper is also honest about its main limitation: the tamper-evident Witness device is a load-bearing assumption, and they say so explicitly in Sections 3 and 7.\n\nThe soft spots are in proportion. The security analysis in Appendix B is a proof sketch, not a full proof; the code and data are not shipped; and the performance benchmarks come from a prototype, not a deployment. On the algorithmic side, the stress-test note is correct: Algorithm 4's first line uses (a2,b3) as the third vertex instead of (a3,b3). That is a typo — the surrounding text and Appendix A use the correct vertex — but as printed it would break the triangle-inclusion check. It should be fixed before the protocol is cited as a reference specification. That is a minor defect, not a fatal one.\n\nOverall, this is a paper worth engaging with. It will be useful to readers working on privacy-preserving compliance, applied ZK, or location privacy. It does not deserve a desk reject; it deserves a serious referee who can check the circuits. I would accept it for peer review with the expectation of a revision that fixes the typo and ideally ships the code.","headline":"Useful applied ZK-PoL feasibility study with honest measurements; the only real defect is a typo in Algorithm 4, and the load-bearing trust assumption is the tamper-evident device.","tokens_in":19001,"tokens_out":1744,"would_cite":true,"duration_ms":17109,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Zero-knowledge protocols let drivers prove mileage and toll-road compliance while keeping their GPS trails private.","keywords":["Zero-Knowledge Proofs","Proof-of-Location","location privacy","vehicle subsidies","road taxation","GPS trails","privacy-preserving compliance","circuit-based geometry"],"falsifier":"Attach the proposed witness device to a test vehicle, drive a known route, then attempt to remove the device, drive outside the subsidized region, or place it on a second vehicle, and try to submit a valid compliance proof from the signed stream; if any such manipulation goes undetected while still yielding an accepting proof, the system's central claim fails, as would any method that produces an accepting proof for a signed coordinate trail the device did not create.","tokens_in":18010,"feed_emoji":"🚗","tokens_out":12292,"duration_ms":120110,"temperature":0.7,"pith_summary":"The paper shows that, with current zero-knowledge-proof technology, a vehicle owner can convince a subsidy authority that a signed GPS trail satisfies a distance and territorial-coverage condition, and can convince a tax authority that toll-road mileage falls in a chosen bracket, without disclosing the raw coordinates. The core idea is to turn policy checks into arithmetic-circuit-friendly geometry: subsidy regions are approximated by unions of circles, taxed roads by the complement of a triangulation, so point-in-region tests reduce to squared-distance inequalities and division-free barycentric-coordinate checks. The protocols bind the proof to the witness device's public key through a hash of the coordinate trail, then assert the linking inequalities $\\mathrm{tot}\\ge d_{\\mathrm{req}}$ and $\\mathrm{cc}\\ge \\mathrm{tot}\\cdot P_{\\mathrm{req}}/100$ for subsidies, or $\\mathrm{tot}-\\mathrm{hw}\\le d_{\\max}$ for highway tax. Measured prototypes put annual proofs at roughly 36 minutes for the EV subsidy and 59 minutes for highway tax on a PC, with much smaller times for trips and months, which the paper argues is tolerable for infrequent, batched compliance proofs. If these numbers hold, large-scale government subsidy and road-tax schemes could enforce territorial rules without the state collecting location histories.","feed_headline":"36/59-minute proofs verify mileage and tolls without revealing routes","feed_subtitle":"Annual zero-knowledge proofs run 36 minutes for EV subsidies and 59 for toll taxes, keeping routes secret.","key_machinery":"The load-bearing mechanism is the reduction of geographic compliance checks to cheap arithmetic circuits. For a subsidy, a point is inside the allowed region if $(x-u_j)^2 + (y-v_j)^2 \\le r_j^2$ for at least one circle $j$, so inclusion uses squared distances and needs no square root; total distance is handled by having the Prover supply each segment length $d_i$ and checking $d_i^2 \\le (x_i-x_{i-1})^2 + (y_i-y_{i-1})^2 < (d_i+1)^2$. For the highway tax, the Prover finds a triangle containing each point, and the circuit checks membership by reconstructing the point from unnormalized barycentric coordinates $(s,t,u)$ with $s+t+u$ equal to twice the triangle's area, which avoids division, then requires $s,t,u\\ge 0$. An oblivious lookup selects the chosen triangle's vertices inside the circuit, and an oblivious ternary update accumulates only the distances whose endpoints both lie in the region. A public hash of the padded trail and the Witness device's signature on that hash anchor the proof to genuine device output while hiding the trail length.","core_discovery":"The discovery is that location-based subsidy and taxation compliance can be expressed as zero-knowledge statements over signed coordinate lists, and the resulting proofs are fast enough to be realistic policy tools. Concretely, Algorithm 1 proves that the sum of segment lengths along a trail is at least a required distance and that the portion with both endpoints inside at least one of a set of circles is at least the required percentage; Algorithm 3 proves that the distance driven outside a set of triangles, taken as the complement of toll roads, is at most a declared cap. Both algorithms first assert that a hash of the Prover's padded coordinate list equals the hash in the public instance, tying the proof to the device-signed trail, then use oblivious selection and checked square roots to accumulate distances without leaking which points are where. The paper presents this as a new combination of formalizing real subsidy and tax rules as relations, approximating geography by circles or triangles, and instantiating the proofs in an interactive zero-knowledge backend. On its own terms, the central claim is that zero-knowledge proof-of-location protocols can make compliance checking privacy-preserving at acceptable computational cost.","pith_inferences":["Editorial: the decisive deployment risk is physical tamper-evidence of the Witness device, not the zero-knowledge cryptography; improvements in cheap, tamper-resistant GPS modules would matter more than faster proof systems.","Editorial: the signed-trail-plus-proof template can be transferred to usage-based insurance, congestion pricing, or supply-chain location audits, since the witness device is policy-agnostic; the paper lists neighboring applications but does not develop them.","Editorial: the Estonia-shaped geometry is favorable; for highly irregular territories the circle or triangle approximations may need many more shapes, so an adaptive shape-selection strategy would be a natural next experiment.","Editorial: replacing the public trail hash with a commitment scheme would remove even the hash disclosure; the paper explicitly accepts the hash leak as not significantly compromising privacy."],"forward_implications":["A subsidy authority can check a rule such as 80,000 km over four years with 80% of distance inside national borders by verifying one zero-knowledge proof and a hash, without collecting or storing the GPS trail.","For road taxation, a driver can prove that toll-road mileage falls in a chosen bracket, e.g. $d\\le y$, and the authority learns only that the bracket is correct, not the route or the exact distance.","Runtime grows linearly with the number of circles or triangles, so accuracy can be traded against cost: the 248-triangle highway model kept the approximated road within 50 m of a real 179 km road.","Annual proofs (43,800 points) took about 36 minutes for the subsidy protocol and 59 minutes for the highway-tax protocol on a desktop-class Prover, and much less for monthly or single-trip inputs, so infrequent proofs can be run overnight or during charging and batched.","Because the Witness device only signs coordinates and does not interpret policy, the same installed hardware can serve future subsidy or tax rule changes without firmware updates."],"supporting_citations":[{"why":"Supplies the three-party proof-of-location model (Witness, Prover, Verifier) that the protocols build on.","marker":"[10]"},{"why":"Supplies the high-level zero-knowledge domain-specific language with an information-flow type system used to write both protocols.","marker":"[4]"},{"why":"Supplies the field-friendly hash function used to commit the Prover's coordinate list to the public instance.","marker":"[22]"},{"why":"Supplies one interactive zero-knowledge backend against which the prototypes were benchmarked.","marker":"[47]"},{"why":"Supplies the other interactive zero-knowledge backend used for the main performance measurements.","marker":"[20]"},{"why":"Supplies the planar projection that keeps distance computation in the two-dimensional circuit cheap.","marker":"[33]"},{"why":"Supplies the driving survey used to map the three benchmark sizes (trip, month, year) to realistic numbers of GPS points.","marker":"[40]"}],"fun_headline_variants":["36-min subsidy proof, 59-min tax proof: routes stay hidden","ZKPs hide routes while proving mileage and tolls in 36/59 min","Private proof of location: verify EV mileage and tolls without coordinates","Zero-knowledge location checks: fast enough for tax and subsidy programs","Route-secret proofs confirm driving distance for taxes and subsidies"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole scheme rests on the witness device being tamper-evident, non-removable, and reliably attached to the vehicle, so that the signed coordinate stream really is the vehicle's driving; if a driver can remove, spoof, or transfer the device without detection, the proof of compliance proves nothing.","fun_headline_variants_meta":{"raw":{"variants":["36-min subsidy proof, 59-min tax proof: routes stay hidden","ZKPs hide routes while proving mileage and tolls in 36/59 min","Private proof of location: verify EV mileage and tolls without coordinates","Zero-knowledge location checks: fast enough for tax and subsidy programs","Route-secret proofs confirm driving distance for taxes and subsidies"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001591,"raw_usage":{"total_tokens":6300,"prompt_tokens":860,"completion_tokens":5440,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":476,"completion_tokens_details":{"reasoning_tokens":5347}},"tokens_in":476,"tokens_out":5440,"duration_ms":44735,"temperature":1.0,"reasoning_tokens":5347,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T19:16:44.650892+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Attach the proposed witness device to a test vehicle, drive a known route, then attempt to remove the device, drive outside the subsidized region, or place it on a second vehicle, and try to submit a valid compliance proof from the signed stream; if any such manipulation goes undetected while still yielding an accepting proof, the system's central claim fails, as would any method that produces an accepting proof for a signed coordinate trail the device did not create.","supporting_citations":[{"cited_title":"Decentralized Proof-of-Location systems for trust, scalability, and privacy in digital societies","cited_arxiv_id":null,"evidence_quote":"Supplies the three-party proof-of-location model (Witness, Prover, Verifier) that the protocols build on."},{"cited_title":"ZK-SecreC: a Domain-Specific Language for Zero-Knowledge Proofs","cited_arxiv_id":null,"evidence_quote":"Supplies the high-level zero-knowledge domain-specific language with an information-flow type system used to write both protocols."},{"cited_title":"Poseidon: A new hash function for{Zero-Knowledge}proof systems","cited_arxiv_id":null,"evidence_quote":"Supplies the field-friendly hash function used to commit the Prover's coordinate list to the public instance."},{"cited_title":"emp-zk — efficient and interactive zero-knowledge proofs, 2023.https://github.com/emp-toolkit/emp-zk","cited_arxiv_id":null,"evidence_quote":"Supplies one interactive zero-knowledge backend against which the prototypes were benchmarked."},{"cited_title":"swanky: A suite of rust libraries for secure computation, 2024.https: //github.com/GaloisInc/swanky","cited_arxiv_id":null,"evidence_quote":"Supplies the other interactive zero-knowledge backend used for the main performance measurements."},{"cited_title":"L-est coordinate system, 2019","cited_arxiv_id":null,"evidence_quote":"Supplies the planar projection that keeps distance computation in the two-dimensional circuit cheap."},{"cited_title":"Steinbach and B.C","cited_arxiv_id":null,"evidence_quote":"Supplies the driving survey used to map the three benchmark sizes (trip, month, year) to realistic numbers of GPS points."}],"review_version":2}