What the PayPal app leaves on an iPhone

Evidence

Confidence: moderate for the device, low for the public record

Device class: Personal iPhones in the Lab's research collection, read as full file system research images. The app was present in 5 of 9 distinct images. App versions 8.98 to 8.107 on iOS 18.5 to 26.2.1.
Evidence source: Read-only inspection of the app's data and app-group containers: database and file names, table and column names, counts. Public web pages, read on 2026-11-06 and listed in the Sources table.
How to reproduce: The parser and three synthetic archives (full, empty, sparse) are in preparation for the open-source project and the Lab artifact repository. Until they are published the device findings cannot be repeated from public files. The public sources can be checked from the Sources table.
Confidence: Moderate that these five installs kept no transactions, contacts, balance or readable token. Low for the public record: no source we read reports misuse of this app itself.
Does not prove: That the accounts were unused, that no payment was made, that the app is unsafe, or that another version behaves the same. All illustrations are synthetic examples.

Cite as

Addai, D., SectraTEK Lab (2026). What the PayPal app leaves on an iPhone. LAB-0011, version 1.0. https://lab.sectratek.com/research/lab-0011/

Citation guide

Methodology note

Drafted with AI assistance and reviewed by the author before publication.

Summary

In five iPhone images the PayPal app kept no readable transaction history, contact list, balance or session token. Its wallet transaction table existed and held 0 rows in all five.
What it did keep is small: a remembered account, settings and consent markers, security-library start records, a cache of request hosts, and a few unsent analytics events.
Payment history and balance are held by the company, and recipients were not on the phone. To answer money questions an examiner needs the account holder's records or a lawful request to PayPal.
The public record is about the category. Regulators and law enforcement describe scams that use payment apps, and scammers who impersonate PayPal. We found no source that reports misuse of the PayPal iPhone app itself.
An empty table is an observation about these installs. It does not show that nobody paid anyone.

What the app does and who uses it

PayPal describes the iPhone app, in its App Store listing, as a way to pay in shops and online, earn rewards, send money at home and abroad, use buy-now-pay-later financing, track packages and manage subscriptions. In its annual report for 2025 the company describes itself as a network that connects consumers and merchants, reports 439 million active accounts at the end of 2025 (an account that completed a transaction in the previous twelve months) and $1.79 trillion in payment volume for the year. Legitimate users rely on it for the things the listing names: paying, getting paid, tracking and managing.

That scale is one reason to look at the app. It is also a reason for care: the same listing carries a privacy label, filled in by the developer, which says that purchases, financial information, contact information and contacts can be linked to the user. That label describes what the company may collect. It does not say what the phone keeps, which is the question here.

Why this app matters to an examiner

An examiner asked about a scam victim's or a suspect's PayPal activity needs to know what the phone can show. First, what the public record says. We read pages from the Federal Trade Commission (FTC), the Consumer Financial Protection Bureau (CFPB), the FBI's Internet Crime Complaint Center (IC3), the Congressional Research Service, the New York State Department of Financial Services (DFS) and the company's own filing. None of them reports misuse of the PayPal iPhone app itself. What exists is a record about the category, about the brand and about one company incident (Figure 1). In every case the misuse described is by third parties, such as scammers and fraudsters, of a legitimate service.

What the public record names, from the app to the category
Level	What the record says	Source and date
The PayPal iPhone app	None found No page we read reports misuse of the app itself.	Pages in the Sources table, read 2026-11-06.
The PayPal brand	Scammers pretend to be PayPal: fake PayPal pages offered to online sellers, and urgent phishing e-mails that use the name. PayPal is named as the impersonated party, not as the wrongdoer.	FTC consumer alerts, 16 June 2022 and 9 May 2023.
Payment apps as a category	Fraud reports, complaints and advice about apps used to send money. PayPal is one of several apps named; the numbers are not split by app.	FTC Data Book (March 2025) and advice (May 2022); CFPB (November 2022, June 2023); IC3 (2026).
The company	A regulator's settlement over a 2022 incident in which criminals used compromised credentials to reach tax forms. It does not mention the iPhone app.	New York DFS, 23 January 2025.

Figure 1The public record by level. The ranking of this app for research rests on the lower two rows. Source: the pages in the Sources table.

The category

The FTC's Consumer Sentinel Data Book for 2024 (March 2025) counts 2,600,678 fraud reports. Of these, 475,905 named a payment method. "Payment app or service" was named in 90,571 reports with $391 million reported lost. That is second only to credit cards in the number of reports (108,881) and third in dollars, after bank transfers ($2,089 million) and cryptocurrency ($1,417 million). Figure 2 shows the ten methods. The category is not one company, and the Data Book says its numbers rest on unverified reports filed by consumers. For 2025 the FTC told Congress on 25 March 2026 that bank payments carried the highest reported losses, then cryptocurrency, and that credit cards were named most often. We read no 2025 split for payment apps.

Show this figure as a table

Reports and reported losses by payment method, FTC Data Book 2024
Payment method	Reports	Reported losses
Bank transfer or payment	47,336	$2,089 million
Cryptocurrency	46,899	$1,417 million
Payment app or service	90,571	$391 million
Cash	13,609	$308 million
Wire transfer	40,448	$287 million
Credit card	108,881	$275 million
Check	8,098	$225 million
Gift card or reload card	41,120	$212 million
Debit card	76,285	$180 million
Money order	2,658	$51 million

Figure 2Reported losses by payment method in 2024. "Payment app or service" is a category, not PayPal. Reports are unverified and counted only where a loss between $1 and $999,999 was stated. Source: FTC, Consumer Sentinel Network Data Book 2024, page 11.

The FTC's consumer advice from May 2022 names Venmo, Cash App and PayPal as apps for sending and receiving money from a phone. It explains that scammers favor payments that are hard to reverse, and it tells people to report a scam to the app and to the FTC. The FBI's 2025 annual report counted 1,008,597 complaints and $20.877 billion in reported losses, and lists peer-to-peer transfer among the transaction types in fraud complaints, without naming a provider.

A November 2022 CFPB staff presentation lists Cash App, PayPal, Venmo and Zelle as major providers of person-to-person payments. It says half of the CFPB's complaints about those payments in 2020 were fraud-related, and that the FTC received nearly 70,000 reports in 2021, totaling $130 million, from people who sent money to fraudsters through payment apps or similar services. The presentation states it is not CFPB guidance. A June 2023 CFPB release on stored funds names PayPal among popular nonbank payment apps and says balances may lack deposit insurance; it does not discuss fraud. A June 2023 CFPB report on servicemembers counted more than 1,100 complaints about digital payment apps in 2022 and names no provider. A CFPB rule that would have supervised the largest payment apps, estimated to cover seven providers including PayPal, took effect in January 2025 and was repealed by Congress later that year, according to the Congressional Research Service.

The brand and the company

Two FTC alerts name PayPal as an impersonated brand. The first, from June 2022, describes buyers who steer an online seller to a fake PayPal page or claim to have overpaid and ask for a refund. The second, from May 2023, describes urgent e-mails that use the PayPal name and give a phone number to call. Both advise people to log in to PayPal directly instead of following a link. The company is the impersonated party in both.

On 23 January 2025 the New York DFS announced a $2 million settlement with PayPal, Inc. for violations of its Cybersecurity Regulation. According to DFS, a 2022 change to how tax forms were made available left them reachable with compromised credentials, PayPal did not then require multifactor authentication, and the company has since remediated. The release does not mention the iPhone app. We include it because it frames takeover of an account with compromised credentials as a recognized risk, which matters when a phone shows a remembered account (Section 5).

PayPal's own security and help pages could not be retrieved by the Lab's tools at the time of writing (the site refused the requests), so none is cited. The App Store listing and the annual filing are the vendor's own words used here.

Why the Lab chose it

We compared the apps found in the Lab's nine distinct research images with what the open-source iLEAPP parser reads, using its public main branch as fetched on 2026-11-06. The images held 731 distinct non-stock apps. The parser read 51 of them, part of 4 more, and none of the other 676. PayPal was in 5 of the 9 images, in three app versions, and had no parser. We ranked the unparsed apps by the relevance of their public record. PayPal came first in the shortlist of ten, but its relevance was rated medium, because the ranking rests on category context only: payment apps lead fraud losses, and no PayPal-specific misuse source was found. That is the honest basis. A second reason is a question the shortlist could not answer without looking: does a payment app leave anything worth reading, or only an empty shell?

Method

We worked on read-only copies of existing research images. For each install we looked in the app's data container and its app-group container, recorded which databases, preference files, logs and caches exist, and noted table, column and key names and row counts. We did not record values, and nothing from a case leaves the Lab. From those names we wrote a parser with nine artifacts for the open-source project, and we built three synthetic archives shaped like a full file system extraction: one with every store populated, one with the stores present and empty, as in the real installs, and one sparse. Every value in them is invented. Files that belong to third-party libraries are read only in a container whose metadata names PayPal, so another app's file with the same name is not reported. A decoy container in the full archive tests that rule.

Tests are the usual ones for the project: 15 unit tests, and three recorded synthetic cases run over nine artifacts. A missing table or key gives no rows and no error. That choice has a cost, which earlier Lab work measured: about 18 percent of the artifacts of one parser suite matched a file and returned nothing (LAB-TR-0006). So here every empty result is tied to a stated reason in the notes, not left as a blank.

What is on the device and what is not

Across the five installs the picture is the same. Transactions, contacts, balance and tokens are not in a readable local store. The wallet table, the card store, the sync queue and the offline QR store are present, which is consistent with the app having places to keep such records, and all are empty. The URL cache holds statistics beacons, advertising attribution, a survey vendor, static assets and one request to the account API host, but no account response. A sealed file in the Documents folder, 1.4 to 3.2 KB with entropy of 7.88 to 7.94 bits per byte, sits on four installs and is consistent with encrypted session data; we did not decode it and read no token.

What the app does leave is Table 1 and Figure 3. Pick a kind of evidence in the explorer to see where it lives, what we found, and what you may and may not say. The same content is in the table under the figure.

This figure needs JavaScript. The table under it holds the same content.

Kind of evidence a reader might hope for

The panel changes as you choose. Counts describe five installs, not a rate.

Show this figure as a table

Nine kinds of evidence: where each lives, what the five installs held, why, and what an examiner may and may not say
Kind of evidence	Where it lives	What we found	Why	You may say and may not say
Payment history	Server-side PayPal's servers, where the company processes the payments.	The wallet transaction table (ZTRANSACTIONENTRY, in the SwiftData store default.store) had 0 rows in 5 of 5 installs. No other store held transaction rows, across 95 SQLite-like and 58 JSON files.	The company processes the payments, so the record of them is with the company. The five installs did not keep a readable copy. The Lab did not test why the table is empty.	May say. No readable payment history was found in this app's container on these five installs. May not say. That no payments were made. That another version, install or state of the app keeps none.
Balance and cards	Server-side PayPal's servers.	No balance in any database, preference file or cache. The card store (card_data.store), the sync queue (sync_queue.store) and the offline QR store were present with 0 rows in 5 of 5 installs.	A balance is a live figure held by the company. A present but empty store is consistent with an app that keeps nothing here.	May say. No balance or card record was found in the container. May not say. That the account held no funds or had no card. Anything about the amount of money in the account.
Contacts and recipients	Cannot say Not on the phone as far as these installs show. Whether the company keeps them is outside the device evidence.	None found in any database, preference file or cache, in 5 of 5 installs.	The App Store privacy label, which the developer fills in, lists contacts among data linked to the user, so the app may handle them. The device evidence cannot say where they end up.	May say. No contact list or recipient list was found in the container. May not say. That the account had no recipients. That the app never read the address book.
Sign-in session	Cannot say A sealed blob in the app's Documents folder. Its content was not read.	Documents/com.paypal.ios.AccountInfo, 1.4 to 3.2 KB, in 4 of 5 installs. Entropy 7.88 to 7.94 bits per byte, which is consistent with encrypted data. Not decoded; no token was read.	The file cannot be read as stored. The iOS keychain was not part of this study.	May say. A sealed session-sized file exists on 4 of 5 installs, an indicator that the app stored session state. May not say. That a session was active, valid or recent. What the blob holds.
Remembered account	On the phone The group preferences file, key RememberedUserV1, a keyed archive.	Present in 4 of 5 installs, with 8 fields: display name, user name, primary e-mail, primary phone, profile id, account type, country code and photo URL. Absent in 1 install whose preferences carry a logout key.	The app writes it on the phone so that the sign-in screen can offer the account again.	May say. The app remembered this account on this phone. Give the file and the key. May not say. That anyone signed in, or when. What the account type number means; that is not established.
Settings and consent	On the phone App and group preferences (the app's own preferences property list and the group file).	26 to 62 rows per install: consent and push opt-in, locale, per-account push channel flags, and first-launch markers named for each app version. The app preferences held 98 to 162 keys per install, many of them server-supplied flags that the parser leaves out.	The app writes these on the phone.	May say. Which app versions were first launched, and the consent and push opt-in as stored. May not say. That the person chose a server-supplied flag. When a setting was changed.
When the app ran	On the phone Date-typed preference keys, a clock reference key and the security SDK's start records.	Dated preference keys: 6 to 13 rows per install. Security SDK start records: 4 to 89 per install, spread over months. A clock reference key fell within minutes of the last SDK log entry in 2 installs.	These are side effects of the app and its libraries running. They are rolling or overwritten stores, not a usage log.	May say. The dates bound when the app wrote to these stores. May not say. That each row is a launch. That a quiet period was a period without use.
Network requests	On the phone The URL cache database (Cache.db), host and path only.	54 to 388 cached requests in the 4 installs where a count was recorded. Statistics beacons, advertising attribution, survey and static-asset hosts, and one request to the account API host. No account API response body was found.	The system caches some responses for the app. Account data does not appear to be cached.	May say. Which hosts the app contacted, and about when, for what remains in the cache. May not say. What a payment sent or received. That a host missing from the cache was never contacted.
Queued analytics events	On the phone com.paypal.lighthouseanalytics/lighthouseanalytics.db, table events.	25 and 5 unsent events in 2 installs, none in 2 others, and no figure in the fifth. In a database all events fell inside one second. The payload names a page, a flow, a login method and an authentication state.	Events wait in this queue until they are sent. Sent events leave it.	May say. For a short moment, which screens and flows the app had queued. May not say. The person's activity over time. That the events were sent, or that no others were.

Figure 3Where does the data live. For nine kinds of evidence it shows whether the phone keeps it, the company keeps it, or the device evidence cannot say. Source: Lab parser report for five installs; App Store listing; PayPal Form 10-K FY2025; LAB-TR-0021.

Table 1 lists the nine artifacts, the stores they read and their limits. Names are schema names, not values.

Table 1. The nine artifacts: source, content, value to an examiner and limits
Artifact	Source file and table	What it holds	Value to an examiner	Limits
Remembered account	Group preferences, key RememberedUserV1 (keyed archive)	Eight fields: display name, user name, primary e-mail, primary phone, profile id, account type, country code, photo URL	Names the account the app offered on the sign-in screen	Not a sign-in and not dated. Account type integer: meaning unknown.
Per-account preference keys	App preferences, keys carrying an account id or e-mail in their name	Eight push channel flags per account, tooltip markers	Shows further accounts the app has handled settings for	The identifier is in the key name. No date.
Dated preference keys	Every date-typed key in app and group preferences; KronosStableTime (Timestamp, Offset, Uptime)	Latest-write dates and a clock reference	Bounds when the app last wrote to its preferences	The latest write to a key, not a history.
App settings and version markers	App preferences: gdprConsented, gdprConsentedDate, push opt-in, locale, appLaunchedFirstTime markers	Consent, opt-in and the app versions first launched	Versions in use, consent as stored	Server-supplied flags (about 100 keys) are left out by design.
Security SDK start records	Thales-v2/slog-TSH-*.log, lines tagged SDKV	Start records of a security library over months	Indirect evidence the app ran on those dates	A record is not shown to be a launch. The log is a rolling store. Header number: meaning unknown.
Cached network requests	Cache.db: cfurl_cache_response, cfurl_cache_receiver_data, cfurl_cache_blob_data	Host and path; fields p, i, t, a of the statistics beacons	Which hosts the app contacted, with a time	No response bodies read. Beacon t matched the cache time to within 2 seconds on every beacon, and i held a private IPv4 address on every beacon; p and a: meaning unknown.
Queued analytics events	lighthouseanalytics.db, table events (event_id, event_session, event_payload, event_ts, dispatch_status and others)	Unsent events with page, flow, login method and authentication state	A short view of screens and flows	Unsent events only. All events of a database fell inside one second.
Analytics SDK sessions (legacy)	Documents/mParticle*.db, table sessions	Session rows of an older analytics library	Leftover dates from an earlier build	Seen in 1 install only.
Wallet transaction store	default.store (app group, SwiftData), table ZTRANSACTIONENTRY	Schema only: amount, date, card id, currency, merchant name, merchant category code and postal code, status columns	Would be the one local record of payments	Empty in all five installs. The reader has run on synthetic rows only; its date convention is unconfirmed.

Figure 4 shows how many rows each artifact returned in each install. The counts range from 0 to 388, and the one artifact meant to hold payments returned nothing everywhere.

Rows returned by each of the nine artifacts in each of the five installs
Artifact	Install 1	Install 2	Install 3	Install 4	Install 5
Remembered account	1	1	1	1	0
Per-account preference keys	2	8	1	0	9
Dated preference keys	9	13	6	7	8
App settings and version markers	46	62	26	26	28
Security SDK start records	5	89	8	4	10
Cached network requests	192	388	–	54	101
Queued analytics events	0	0	–	25	5
Analytics SDK sessions (legacy)	–	5	–	–	–
Wallet transaction store	0	0	0	0	0

Figure 4Rows returned by each artifact in five installs. Shading: none, 1 to 9, 10 to 99, 100 or more; a dash means no figure for that install. The numbers carry the meaning, not the shade. Source: Lab parser report for five research images. Counts, not rates.

Two cautions. First, the analytics queue holds only events not yet sent, and a store like this is not a log: it says nothing about the days before or after. Earlier Lab work measured that the reach of a rolling store belongs to the store, the release and the device (LAB-TR-0021). Second, a remembered account is a convenience the app writes so the sign-in screen can offer the account again. It was absent in the one install whose preferences carry a logout key, which fits the idea that signing out removes it, but we did not test that.

What an examiner can and cannot conclude

An examiner can say that the app was installed, at which versions, and that it remembered a named account when the evidence was taken. Dated keys, security-library records and the request cache bound when the app wrote to its stores. If a wallet table ever holds rows, report them as stored and say that the date convention is unconfirmed.

An examiner cannot read payments, balances or recipients from the phone on these five installs, and should not report an empty table as "no transactions". The reader's result is "no rows in a store that exists", which licenses a statement about the store. It does not license one about the account. Lab work on absence claims explains why: a claim that nothing happened needs a store that could have recorded it (LAB-TR-0034). For money questions, the sources are the account holder's own statements and records, and a lawful request to the company. A remembered account also does not tell you who held the phone. The regulator's account of compromised credentials is a reminder that a sign-in can be made by someone else, so link the account to the person with other evidence.

What this does not prove

Read these before you report a finding

Empty tables in five installs do not prove that no payment was made, that the accounts were unused or that other versions keep nothing. The Lab did not test why the tables are empty.
The public sources do not show that the PayPal iPhone app is misused more than any other payment app. The numbers are about categories and are unverified consumer or complainant reports.
Nothing here accuses the company. Misuse described in the sources is by third parties of a legitimate service, and the DFS settlement is the regulator's account of a 2022 incident that did not involve the iPhone app.
The sealed session file is not shown to hold a token. The iOS keychain was not part of this study.
The wallet reader has not run on a populated store. Its date and amount columns are shown as stored.
The counts describe five installs of app versions 8.98 to 8.107 on personal iPhones and are not rates. Android and macOS apps were not examined.

Sources

Every number and claim, and where it comes from. Web pages were read on 2026-11-06. PayPal's own security and help pages returned an access refusal and are not cited. Numbers that could not be sourced were left out. LAB-TR-0021 and LAB-TR-0034 are Lab Technical Reports available on this site, with no DOI yet (LAB-TR-0021, LAB-TR-0034); LAB-TR-0006, Empty Is Not Absent, is on Zenodo (doi:10.5281/zenodo.23717928).

Sources for the numbers and claims in this article
Claim or number	Source
What the app is for: pay in stores and online, rewards, send money domestically and abroad, buy now pay later, package tracking, subscriptions. Developer-reported privacy label: purchases, financial info, contact info and contacts linked to the user.	Apple App Store listing "PayPal - Send, Shop, Manage", seller PayPal, Inc. apps.apple.com/us/app/paypal-send-shop-manage/id283646709, read 2026-11-06.
439 million active accounts at 31 December 2025 (an account that completed a transaction in the past 12 months); $1.79 trillion total payment volume in 2025; self-description as a network connecting consumers and merchants.	PayPal Holdings, Inc., Form 10-K for the year ended 31 December 2025, SEC. sec.gov, pypl-20251231.htm.
2,600,678 fraud reports in 2024; 475,905 named a payment method; payment app or service 90,571 reports, $391 million; credit cards 108,881 reports, $275 million; bank transfer or payment $2,089 million; cryptocurrency $1,417 million; the other methods in Figure 2; reports are unverified and losses count only $1 to $999,999.	FTC, Consumer Sentinel Network Data Book 2024, March 2025, pages 2, 3 and 11. ftc.gov, csn-annual-data-book-2024.pdf.
2025: bank payments had the highest aggregate reported losses, followed by cryptocurrency; credit cards were most frequently named. No payment-app figure for 2025 was read.	FTC, prepared statement before the Joint Economic Committee, 25 March 2026. ftc.gov, testimony PDF.
Venmo, Cash App and PayPal let people send and receive money from a phone; scammers favor payments that are hard to reverse; report to the app and to the FTC.	FTC Consumer Advice, "Mobile Payment Apps: How To Avoid a Scam When You Use One", May 2022. consumer.ftc.gov.
Fake PayPal page offered to online sellers; overpayment refund request; advice to log in to PayPal directly.	FTC Consumer Education, "Online sellers stung by scammers spoofing PayPal brand", 16 June 2022. consumer.ftc.gov.
Urgent e-mails using the PayPal name with a phone number are phishing; the scammers send them.	FTC Consumer Alert, "Those urgent emails from MetaMask and PayPal are phishing scams", 9 May 2023. consumer.ftc.gov.
1,008,597 complaints and $20.877 billion in reported losses in 2025; peer-to-peer transfer listed as a transaction type in fraud complaints; no provider named.	FBI Internet Crime Complaint Center, 2025 IC3 Annual Report, 2026. ic3.gov, 2025_IC3Report.pdf.
Cash App, PayPal, Venmo and Zelle as major P2P providers; 50 percent of P2P complaints to the CFPB in 2020 fraud-related; nearly 70,000 FTC reports in 2021, $130 million, from payment apps or similar services; the presentation is not CFPB guidance.	CFPB staff presentation, "Person-to-Person (P2P) Payment Fraud Conversation", November 2022. files.consumerfinance.gov.
PayPal, Venmo and Cash App named as popular nonbank payment apps; stored balances may lack deposit insurance; no mention of fraud.	CFPB press release, 1 June 2023. consumerfinance.gov, archive.
More than 1,100 servicemember complaints about digital payment apps in 2022; no provider named.	CFPB press release, 20 June 2023. consumerfinance.gov.
CFPB larger-participant rule estimated to cover seven providers including PayPal; effective 9 January 2025; repealed by Congress in 2025 (P.L. 119-11).	Congressional Research Service, In Focus IF12935, 4 March 2025, updated 12 June 2025. everycrsreport.com/reports/IF12935.
$2 million settlement announced 23 January 2025; 2022 change to tax-form access; compromised credentials; no multifactor authentication then; remediated since. No count of people affected is given.	New York State Department of Financial Services press release, 23 January 2025. dfs.ny.gov, pr20250123.
Device findings: app in 5 of 9 images, versions 8.98 to 8.107, iOS 18.5 to 26.2.1; local-or-server table; rows per artifact; the empty wallet, card, sync and offline QR stores; the sealed 1.4 to 3.2 KB file and its entropy; 15 unit tests and three synthetic cases over nine artifacts.	Lab parser report for the app (agent_paypal), 2026-11-06, aggregate counts and schema names only.
731 distinct non-stock apps; 51 parsed, 4 partial, 676 not; PayPal in 5 of 9 images and rated medium relevance on category context; survey against iLEAPP main (512 plugin files) fetched 2026-11-06.	Lab inventory report, "iOS FFS non-stock app inventory vs iLEAPP", 2026-11-06.
About 18 percent of the iOS artifacts of one suite matched a file and returned nothing.	LAB-TR-0006, Abstract (Zenodo, concept DOI 10.5281/zenodo.23717928).
A store's reach belongs to the store, the release and the device. A claim that nothing happened needs a store that could have recorded it.	LAB-TR-0021, Abstract; LAB-TR-0034, Abstract.

Version history and corrections

Version history
Version	Date	Change
1.0	2026-11-06	First publication.

Corrections log

No corrections have been published for this article. Corrections to any article are listed on Corrections, with the version they apply to.