History CSV Export
Panther Protocol aims to offer both privacy and transparency from the dApp. To this end, the Historical CSV Data Export feature allows users to voluntarily export a comprehensive history of all transactions associated with their zAccount. Notably, these transactions are not linked to the public addresses of the dApp users, enhancing transactional privacy.
The CSV file provides a full record of the user’s transactions — maintaining a transparent and traceable personal record.
Furthermore, this feature supports voluntary disclosure. Users have granular control over the generation and sharing of their transaction history, giving them nuanced control over whether to maintain privacy or provide transparency according to the intended recipient of the data.
Using their encrypted on-chain data, users can generate audit files from within the dApp:
View Transaction History
Users can view/search their past transaction via the interface within the History tab within the dApp. This action triggers the compilation of their transaction history.
Export
Users can click the export button and download their transaction history as a CSV file.
Compliance and reporting
For users requiring transaction history for compliance or reporting purposes, this feature provides a detailed and verifiable record without compromising privacy.
Personal record keeping
Users seeking to maintain personal records of their digital asset movements can utilize this feature for organized and accessible transaction history.
While the Historical CSV Data Export feature is designed to offer detailed transaction history, user privacy remains a paramount concern. All exported data is handled with strict privacy measures, ensuring that user identities and their association with public blockchain addresses remain confidential. Users are encouraged to safeguard their exported data with the same diligence they apply to their private keys and other sensitive information.
ZK and Non-ZK Reveals
Each transaction results in an encrypted “message to self” stored on-chain
Similarly, to support forensic reveals, each transaction results in an encrypted “message to data escrow”
Account holders can choose what of this, and their KYC data, they reveal and to whom
Account holders may provide ZK proofs rather than the raw data
When users transact from a zAccount, they create an encrypted “message to self” to be stored on-chain — accessible with their private key. In this way, basic details of the transaction event, such as the asset type and value and when ownership was relinquished, are retained. The account holder, however, can’t reveal anything about the recipient of a transaction, other than the zAccount’s Id.
Account holders may then select what transaction and KYC data they reveal and to whom.
Panther Protocol uses Zero-Knowledge, ZK proofs to give users more control over their data. Rather than users sharing their personal information with every institution or protocol they interact with, Panther instead allows them for each use case (e.g. one for proof of address, one for identity, etc.) to interact only once with only a single trusted party (a Trust Provider) which can verify their information and issue a signed cryptographic attestation.
Users can then use these attestations to issue an unforgeable mathematical proof, verifiable on- and off-chain, which Service Providers can reference and verify. This indicates that the user has the attributes, credentials, or reputation needed to participate in a transaction, with selective sharing of personal data. The user can make a given Panther Reveal (carrying no personal data) or non-ZK (carrying personal data). Both would be verifiable by anyone if submitted on-chain.
Furthermore, ZK Reveals are generalizable across other segments such as private identity, insurance, credit scoring, Web3 authentication, and other services.
Once a Service Provider (such as a KYC verifier, institutional DeFi service, or Web3 protocol) receives a Panther ZK Reveal, they don’t learn the underlying information; only that the proofs are valid and the users’ claims are true. Also, the Trust Providers who issued the attestations never learn when or how users use those attestations when interacting with Service Providers.
Status | Entrypoint |
---|---|
Status | Entrypoint |
---|---|
Concept
Concept