You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A series of tickets to rebuild the Fuse <> Celo microbridge as a microservice, and implement into GoodDapp.
Detailed Description of Functionality
The user should be able to swap from G$ Fuse <> G$ Celo either way based on the following logic:
The max that is in total possible to bridge is variable depending on how much has been bridged
daily-limit: 30mG$
txlimit: 5mG$
Fee breakdown (should translate to 0.15% of total amount):
min fee = 10G$
max fee = 1MG$
with relay (third party confirms / executes your transaction for receiving tokens): 50% is bridgeFee / 50% is relay-fee
with self-relay: 50% is bridgeFee / the remaining fee is added back to your receive amount
I believe that the bridgeFee is just gooddollars that stay in the bridge
Technical Implementation
*Outline the technical approach for building the feature. This section is typically filled out by the development team or can contain suggestions.
(dev team: @johnsmith-gooddollar@sirpy@L03TJ3)
(What api's / sdk's could possibly be used)
Design Reference
See individual tickets.
Acceptance Criteria
Specify criteria that will be used to determine if the feature meets the requirements and functions correctly.
(Should include a list of testing points for QA how to verify design/functionality)
The text was updated successfully, but these errors were encountered:
Business Description
A series of tickets to rebuild the Fuse <> Celo microbridge as a microservice, and implement into GoodDapp.
Detailed Description of Functionality
The user should be able to swap from G$ Fuse <> G$ Celo either way based on the following logic:
The max that is in total possible to bridge is variable depending on how much has been bridged
Fee breakdown (should translate to 0.15% of total amount):
Technical Implementation
*Outline the technical approach for building the feature. This section is typically filled out by the development team or can contain suggestions.
(dev team: @johnsmith-gooddollar @sirpy @L03TJ3)
Design Reference
See individual tickets.
Acceptance Criteria
Specify criteria that will be used to determine if the feature meets the requirements and functions correctly.
The text was updated successfully, but these errors were encountered: