🎒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.

Last updated