# Use case for adding Solana network transactions to G1nkgo. ## User point of view 1. The user will have an option in the *"Info"* tab called "instant payment". 2. When switching it on/off * a. if there is no bridging happening, an explanation is shown to indicate that the operation will take some time but can be cancelled and ask for confirmation. * b. if there is a bridging happening, an explanation is shown asking if the operation should be cancelled. If the user validates, the operation is reverted. 4. The user has the same amount of G1 in the wallet and keep the same address. 5. OPTIONAL: The G1nkgo card could have a specific look and feel and a specific name like changing from *vjrj :heart_decoration:* for standard payment (G1nkgo Duniter) to *vjrj :diamond_shape_with_a_dot_inside:* for instant payment (G1nkgo Solana). ## Developer point of view **PREREQUISITE: If the G1nkgo wallet does not have a Solana address, create one with the Solana library and store the private key into local storage along Duniter private key.** 1. When the user activates the "instant payment" option: * a. If there is no G1_Duniter in the wallet ==> nothing happens * b. If there is G1_Duniter in the wallet ==> the G1_Duniter is automatically sent to a specific G1 Duniter address which is a bridge address. 2. G1nkgo scans periodically to see if the transaction is validated by the Duniter network. When the G1_Duniter is arrived on the bridge address: * a. A Solana address is linked to the Duniter address * b. Transfer G1_Solana from the bridge to the Solana address 3. When sending a transaction: * a. "instant payment" option activated ==> the payment is transfered instantaneously via the Solana network by using Solana library **WARNING: if the user didn't updated it's G1nkgo wallet and does not have a Solana address linked to its Duniter Address, the Solana transfer would fail with the "recipient not found" error. In that case, display a message to incitate the recipient to update its version** * b. "instant payment" option deactivated: * If the recipient has "instant payment" activated, send the G1_Duniter to the bridge with the recipient address * If the recipient has "instant payment" deactivated, send the G1_Duniter through Duniter (standard transfer) 4. When receiving a transaction: * a. "instant payment" is activated and the transaction is from Solana (instant) ==> GREAT!! * b. "instant payment" is not activated and the transaction is from Duniter ==> do nothing. * c. "instant payment" is activated and the transaction is from Duniter ==> IMPOSSIBLE! If the sender detects that the instant payment is activated, the G1_Duniter will be sent to the bridge directly. * d. "instant payment" is not activated and the transaction is from Solana (instant) ==> ask to activate "instant payment". * If accepted and the wallet balance is empty, switch the option "instant payment" to on. * If accepted and the wallet balance is not empty, switch the option "instant payment" to on AND send the current balance in G1_Duniter to the bridge and receive G1_Solana. * If refused, send the received payment in G1_Solana to the bridge and receive G1_Duniter. 5. When the user deactivates the "instant payment" option: * a. There is no G1_Solana in the wallet ==> nothing happens * b. There is G1_Solana in the wallet ==> send all G1_Solana to the bridge address, wait for Solana validation AND transfer equivalent amount of G1_Duniter from the bridge to the Ginkgo wallet. ## How the bridge works 1. The bridge is composed of two specific addresses: - one specific Duniter address which role will be to keep G1_Duniter - one specific Solana address which role will be to keep G1_Solana 2. At the begining, the bridge will have 0 G1_Duniter and 1 000 000 G1_Solana. When X G1_Duniter is received from a Duniter address, X G1_Solana is sent to a Duniter linked Solana address. As a result, at all time, the bridge should have 1 000 000 G1 when adding G1_Duniter and G1_Solana. 4. For security reasons, the bridge's private keys (Solana and Duniter) should be encrypted and the secret to recover the private key should be splitted to trustworthy persons. At least, two distincts persons, one with the Solana secret and the other with the Duniter secret. See https://en.wikipedia.org/wiki/Secret_sharing 4. G1nkgo should be able to sign transactions with both keys (Solana and Duniter). 5. If the user cancels a bridging process while happening, the Duniter transaction should be cancelled. That should be like cancelling a standard Duniter transaction. Nothing happens to the Solana transaction as it can not be cancelled once send. * a. if an "instant payment" activation is cancelled, the G1_Duniter is restored to the wallet * b. if an "instant payment" deactivation is cancelled, the G1_Solana is restored to the wallet ## Transfer uses cases 1. Both the sender and recipient have "instant payment" ==> payment is sent via Solana (instantaneous) directly to the recipient 2. Both the sender and recipient don't have "instant payment" ==> payment is sent via Duniter (slow) directly to the recipient 3. The sender don't have "instant payment" but the recipient has "instant payment" ==> payment is sent via Duniter (slow) to the bridge and when the payment is received, the same amount is sent from the bridge to the recipient via Solana (instantaneous) 4. The sender has "instant payment" but the recipient don't have "instant payment" and his wallet is empty ==> payment is sent via Solana (instantaneous) directly to the recipient. G1nkgo asks the user if he wants to switch to "instant payment": * a. If yes, nothing happens. * b. If no, the payment is sent via Solana (instantaneous) to the bridge and when the payment is received, the same amount is sent from the bridge to the recipient via Duniter (slow) 5. The sender has "instant payment" but the recipient don't have "instant payment" and his wallet is not empty ==> payment is sent via Solana (instantaneous) directly to the recipient. G1nkgo asks the user if he wants to switch to "instant payment": * a. If yes, the wallet balance is sent via Duniter (slow) to the bridge and when the payment is received, the same amount is sent from the bridge to the recipient via Solana (instantaneous) * b. If no, the payment is sent via Solana (instantaneous) to the bridge and when the payment is received, the same amount is sent from the bridge to the recipient via Duniter (slow) **In summary, in case 1 and 4a, payment is instantaneous, in other cases the payment is as usual.** ## Diagram Below is a diagram to illustrate uses cases 1, 4a et 4b