Transactions make using Ledger Fresh must be followed until there are accepted on layer 2. The user must be able to follow their status to be sure everything goes well.
Full description
A Starknet transaction can have 6 different statuses:
NOT_RECEIVED
RECEIVED
PENDING
REJECTED
ACCEPTED_ON_L2
ACCEPTED_ON_L1
The user must know in real-time if the transaction is broadcasted and has already been accepted on layer2 or not. Until it is not accepted (or the transaction has not been flagged as rejected) the user must have a way to check the status of the transaction he broadcasted.
As it is possible for a user to broadcast multiple transactions without necessarily waiting for the last one to be included on layer 2, the UI must be prepared to accept a list of transactions.
Once the transaction is accepted on layer 2, the user must be informed and the transaction must be removed from the list.
In order to know which transaction should or shouldn't be watched, I suggest including the hash of the transaction in the local storage once it is broadcasted. Once the transaction is accepted, the hash has to be removed from the local storage. All transactions in the local storage must be watched by what you are going to develop in this task.
The service that will request the status of any transaction must be a serverless function embedded in the next application. The same third-party service must be used for requesting transaction statuses and for requesting account balances.
This is an automatic post that is intended to facilitate the follow-up of the project.
This post is meant to be edited throughout the life of the project.
Header
Name of the task: Transaction watcher
Name of the module: Web
Difficulty: 3
Waiting for: /
Body
Short description
Transactions make using Ledger Fresh must be followed until there are accepted on layer 2. The user must be able to follow their status to be sure everything goes well.
Full description
A Starknet transaction can have 6 different statuses:
NOT_RECEIVED
RECEIVED
PENDING
REJECTED
ACCEPTED_ON_L2
ACCEPTED_ON_L1
The user must know in real-time if the transaction is broadcasted and has already been accepted on layer2 or not. Until it is not accepted (or the transaction has not been flagged as rejected) the user must have a way to check the status of the transaction he broadcasted. As it is possible for a user to broadcast multiple transactions without necessarily waiting for the last one to be included on layer 2, the UI must be prepared to accept a list of transactions. Once the transaction is accepted on layer 2, the user must be informed and the transaction must be removed from the list. In order to know which transaction should or shouldn't be watched, I suggest including the hash of the transaction in the local storage once it is broadcasted. Once the transaction is accepted, the hash has to be removed from the local storage. All transactions in the local storage must be watched by what you are going to develop in this task.
The service that will request the status of any transaction must be a serverless function embedded in the next application. The same third-party service must be used for requesting transaction statuses and for requesting account balances.
Additionals ressources