🎒How is it stored?

Let's delve into the storage and structure of transaction requests to understand how they're stored and verified:

1. Structure of Transaction Request

Transaction requests can reside in one of three states:

• Fulfilled: This state is achieved once a user has successfully paid a transaction request.

• Pending: This is the state when a transaction request is freshly created but hasn't been processed by the user.

• Expired: A transaction request transitions to this state when the current time surpasses its set expiration time.

2. Storage Mechanism

For ensuring security and traceability:

• Every version undergoes a SHA-256 hashing process.

• If the second version of a transaction request is absent, a placeholder null SHA-256 hash (e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855) steps in.

• These hashes are then funneled into a merkle root generator function. The resulting merkle root is diligently stored on the target blockchain. This setup empowers users to authenticate whether their off-chain transaction requests are legitimate.

3. Verification Process

For payment platforms like wallets, there are a couple of options:

• Trust Offchain Data: Platforms can choose to rely on offchain data, but they should be fully aware of the associated risks.

• Verify Offchain Data: If platforms opt for verification:

  • They can solicit a proof from the offchain server.

  • Using the acquired proof, they can invoke the verifyMerkleProof function on their provider's contract.

  • By submitting the proof alongside the owner's address, they'll receive a straightforward true or false response, denoting the validity of the transaction request.

Note: Change transaction requests to pull payments

In essence, this framework ensures both the integrity and traceability of transaction requests, offering users and platforms a secure and transparent experience.