Since PDAs are private by default, that data cannot be accessed directly by a third party. To facilitate data exchange in a secure and privacy-preserving manner, Data Proofs are used to send data to users and businesses looking to leverage that information. Oftentimes, Data Proofs are the results of a Data Request by a Requestor but does not necessarily have to be.

​

Parties Involved

The two parties involved in this transaction include the owner and the verifier.

The Owner is giving explicit permission to the Verifier to access the information they hold.

This interaction does not require issuer consent.

​

Consent Management

To ensure compliance with GDPR and other leading privacy regulations, for Data Proof to be conditioned, there must be explicit consent from the owner for the verifier to access the data.

Gateway Protocol records this consent as a transaction on Arweave, so it is permanently verifiable.

The consent is given as a non-reputable cryptographic signature generated by the user’s wallet. This consent, along with the request ID, is recorded on Arweave to create permanence and easy reference for the verifier and owner to check against the consent given at any point.

​

UUID

Each Data Proof has an associated UUID with that is unique between the owner who shared the information and the verifier who received it.

​

Data Proof Status

The ‘status’ field within the Data Proof serves as an indicator of its current relevance. Should any of the Private Data Assets (PDAs) within the Proof undergo an update, the Proof’s status will automatically switch to ‘Outdated.’ At this juncture, verifiers have the option to reinitiate the request, prompting the owner to submit the most current PDA information.

​

How is it structured?

Private Data Assets (PDAs) are categorized by their data model ID in a Data Proof. While a Data Proof will always contain at least one PDA, the number can vary based on the owner’s discretion and the specifications of the Data Request, if applicable. Verifiers can access the PDA data using the API or the dashboard.

​

Other Pieces

Each Data Proof also contains information about:

1. Data Request (if any)
2. Data Request Template (if any)
3. Timestamp of Proof Creation

​

Cost Burden

The cost structure for a Data Proof is both clear and uncomplicated. It’s calculated as follows:

Total Cost => i = 1∑N(Cost Per PDA for Data Model i * Number of PDAs from Data Model i) + Gateway Facilitation Fee

For instance, if a Data Proof includes three PDAs from the ‘Credit Card Transaction’ Data Model, each costing $0.10, and two PDAs from the ‘Credit Score’ Data Model, each costing 0.20 USD.

Gateway adds a 5% facilitation fee to the sum. The total cost for this Data Proof would, therefore be:

((3*$0.10)+(2*$0.20))*1.05=$0.735

In this example, the issuers of the PDAs would collectively receive $0.70, and Gateway would earn a facilitation fee of$0.035. The per-PDA cost for each Data Model is readily available for reference.

To enhance the predictability of Data Request costs, we include the average cost of fulfilling a request—also known as the ‘proof cost’—right within the Data Request Template. This way, you get a clear financial picture upfront, streamlining your planning and decision-making processes.

​

Verifier Requests Information

If the verifier receives the Proof through a request they made, they are responsible for paying the cost. This will be invoiced to them on a monthly basis. To learn how Verifiers can make requests, click here.

​

Owner Sends to Verifier

If the Owner sends the Proof without an associated Data Request, the Recipient is responsible for paying the cost of the Proof.

---

​

Privacy + Security

Gateway takes privacy and security of the underlying data you own quite seriously. To ensure that only the verifier (receiving party) is the one seeing the information, Data Proofs employ a two-tier encryption strategy for enhanced security.

Initially, the data is encrypted using a one-time symmetric key, which ensures fast and efficient encryption. This symmetric key itself is then encrypted using the intended recipient’s public key. This approach marries the speed of symmetric encryption with the security of public-key encryption, making sure that only the intended recipient, who possesses the corresponding private key, can decrypt the symmetric key and, by extension, the data. This dual-layer encryption not only enhances security but also ensures that the data remains confidential and accessible solely by the designated user.

Reasons for this approach include:

1. Speed: Symmetric encryption is generally faster than public-key encryption, making it ideal for encrypting any size proof - even ones that may contain hundreds of PDAs.
2. Security: By subsequently using public-key encryption for the symmetric key, the data gains an additional layer of security. This also ensures that even if the symmetric key is compromised, the data remains secure unless the recipient’s private key is also compromised.
3. Integrity and Confidentiality: The usage of the recipient’s public key ensures that the data can only be decrypted by the intended recipient, thus maintaining both the integrity and the confidentiality of the data.
4. Non-repudiation: Encrypting with the recipient’s public key also provides a layer of non-repudiation, as only the intended recipient could have decrypted the data.
5. Flexibility: This two-tier approach can be easily adapted to various data types and transmission protocols, making it versatile for different use cases.