🌐 Bridgoro.com - BETA TEST! Active until December 7th!!

[examplens]

I tried underfunding a transaction again. Now I receive this email:

Code:

Dear Seller,
We have detected an underpayment for your offer. The partially confirmed deposit amount is less than the required amount.
~
Your transaction will be refunded shortly once we receive all the confirmations. Next time, please make sure to send the exact amount you specified when creating the offer.

Works fine now

Have you tried how the platform behaves in case of RBF use? What happens if the Bridgoro platform recognises a transaction on the blockchain, which is later replaced by a new one?
Is the order ID linked to the TX ID, or to the amount of deposited coins after 1st confirmation?

As I say, I didn't test, I don't even have testnet coins now, I see that LoyceV a.k.a. LauraV is in the process of testing.
Just ignore if this has already been discussed.

[Bridgoro]

This will make it less likely, but not impossible to occur: my transaction must have had about 145 inputs, and it's possible for a user to have collected more small inputs.

Everything is possible, which is why we need more time for a deeper investigation.

I won't claim I know much about Monero's internal workings, but I found this:

So the transaction splitting function is not an anonymity thing, it's due to the dynamic block size limiter. Right now testnet is on the block median, and you're trying to create a transaction that is much larger than that block limit.

-- fluffyponyza, Dec 14, 2016

Based on the above, it could be this is much less likely to occur on real Monero than on testnet.

We also assume that the Monero GUI splits transactions more frequently on testnets than on mainnet, but we want to verify this. Even after the Beta ends, we will publish our research here and make sure to mention you.

I've Cancelled Offer ID: cafac829-b0fc-4fc2-a2a3-5863eaff6204, and received a return payment:
Inputs:

Code:

4783950x24x1   	tb1q4dnrml9y4czawmgvjyvf7gp34gups4fwel72m7	     0.003117

Outputs:

Code:

358cac89d9:0   	tb1q6hlep3yytgv6q0dl8uuj932y9hvhwnqqzvhza5	     0.00311248
358cac89d9:1   	tb1q7nqts63qz0w8j5k97jwprsupsaxwg8q3j9sndv	     0.00000311

So the refund went to the first address I sent from. If I would have sent this from an exchange, the rollback would be lost for me.

We will figure out where to place a warning message advising users not to send funds directly from an exchange and to use a native wallet temporarily.

When I Canceled my Offer, Bridgoro took a fee. Is that as intended? If so: Let's say a user creates an Offer, and nobody buys it. After a few days, he Cancels his offer to get his money back (and try elsewhere). If he still has to pay a fee for an Offer that wasn't sold, he's going to be very disappointed and probably won't return.

The fee that was deducted is used strictly for the network fee.

I tried underfunding a transaction again. Now I receive this email:

Code:

Dear Seller,
We have detected an underpayment for your offer. The partially confirmed deposit amount is less than the required amount.
~
Your transaction will be refunded shortly once we receive all the confirmations. Next time, please make sure to send the exact amount you specified when creating the offer.

Works fine now

Yeah, we prioritize fixing minor bugs first since they take less time to resolve.

Have you tried how the platform behaves in case of RBF use?

If you mean Replace-by-Fee, then yeah that's a good point!
This also needs to be tested.

What happens if the Bridgoro platform recognises a transaction on the blockchain, which is later replaced by a new one?
Is the order ID linked to the TX ID, or to the amount of deposited coins after 1st confirmation?
As I say, I didn't test, I don't even have testnet coins now, I see that LoyceV a.k.a. LauraV is in the process of testing.
Just ignore if this has already been discussed.

The confirmed amount on the blockchain cannot be replaced.

[CONVOAI]

UI/UX overlap and z-index hierarchy problem
On mobile devices, the user profile dropdown menu is overlapping the primary CTA buttons "Start Exchange" and "Start Earn".


Overlay Modal Exceeds Viewport and Overlaps Browser UI
The beta notification modal does not show fully on mobile devices. The title above is not fully visible. A scrollbar needs to be placed here.

[LoyceV]

Have you tried how the platform behaves in case of RBF use?

I'll test this later, December 5 is kids-day here

When I Canceled my Offer, Bridgoro took a fee. Is that as intended? If so: Let's say a user creates an Offer, and nobody buys it. After a few days, he Cancels his offer to get his money back (and try elsewhere). If he still has to pay a fee for an Offer that wasn't sold, he's going to be very disappointed and probably won't return.

The fee that was deducted is used strictly for the network fee.

That would make sense, but it's not what happened. See my Rollback Transaction:
The transaction fee was 141 sats, and 311 sats (0.1%) was sent to tb1q7nqts63qz0w8j5k97jwprsupsaxwg8q3j9sndv, which I assume is Bridgoro's address.

Follow-up (a day later): someone took one of my Offers, and sent a payment:

Code:

4789745x8x0    	tb1q52rktesraglsm5kq7wzthshm7v7vy2csxnth22	     0.02000254
4789745x8x1    	tb1qf8zs6nmfxec2ert5rzakkpmnjz9m3d986d0lp2	     0.00000311

Here, there's 311 sats going to another address again. I expected the fee to be a percentage, and I've seen different values for some transactions, but most of them end up sending exactly 311 sats to another address.

[btcnbegun]

Vulnerable JS Library
https://bridgoro.com/assets/index.24a38bbe.js
Current version : DOMPurify, version 3.3
CSP Header Not Set[/size]
https://bridgoro.com
the img-src directive is set to 'self' bridgoro.com.
Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

We recently mentioned that CSP, X-Frame, and other related headers will be implemented later, once internal testing is complete.
Here is the reference to our earlier note: https://bitcointalk.org/index.php?topic=5555796.msg66126694#msg66126694

We attempted to implement these headers after receiving the first report on Telegram, but it introduced multiple bugs and caused issues with correct data rendering on Bridgoro.


TCP Timestamps Information or Session expiry
bridgoro.com

TCP timestamp is enabled (default setting)

Code:

set tcp-option disable    <-- Default value is enable

It was detected that the host implements RFC1323/RFC7323.

The following timestamps were retrieved with a delay of 1 seconds in-between:
Packet 1: 1386648869
Packet 2: 1867871899

There was a delay of 1 seconds in-between packets

This can cause a time-based authentication protocol to lose therefore allowing to compute the uptime

  

[LoyceV]

If you mean Replace-by-Fee, then yeah that's a good point!
This also needs to be tested.

I tried RBF on BTC, while creating an offer to trade BTC for XMR. There's a blockstorm on testnet at the moment, so I only have a few seconds for RBF.
I tried 4 times:
1. Offer ID: fd9a8340-498d-4c69-b74d-64dbe98fb312: RBF failed, the initial transaction confirmed. This Offer is Active.
2. Offer ID: c4f9b59e-0173-4be8-8d00-4d9d26770dd9: RBF succeeded, the initial transaction was replaced. This Offer is stuck as "Partially Confirmed". Interesting detail: I entered amount 0.0006, and sent 0.0006. BUT: My Offer Details now shows Amount to be deposited: 0.00059999. How did this happen?
3. Offer ID: 4d06b394-798a-4938-959e-52d6e90d4b9c: RBF failed, the initial transaction confirmed. BUT: This Offer is stuck as "Partially Confirmed". I think Bridgoro may have picked up on the RBF transaction (the one with higher fee) before it saw the first lower-fee transaction, and got stuck when the low-fee transaction got confirmed. I'm just guessing what happened here.
4. Offer ID: c01e3649-73ba-467f-ab57-dc72ee96780d: RBF succeeded, the initial transaction was replaced. This Offer is stuck as "Partially Confirmed".

I think the RBF implementation needs some work

[fruktik]

Today I decided to complete the tasks again and check the bonus accrual. So far, everything is working as expected. The bonuses have been credited to my account. However, when I click the "Claim" button again, I'm a bit alarmed by the pop-up message in the lower right corner. The idea is really good. It will help keep the audience on the site.




A good option would be to move this status to a button to avoid confusion for users. It's not very visually convenient to check it in a separate block.

[masulum]

Transaction detail:
Offer ID: d1f0eccc-3ebc-4aba-a0c7-34bbc76b53aa
Solana buffer address: ARhSHx9W1qoRi2vKuaQZuY5NXck6E13Kywu7tUhhetbq
Hash of Deposited Solana: https://solscan.io/tx/52Hkd2nLqi5QjdAFnzfVEohHy2VXCrY86GcUiK7TgpzjKN177U5N49VEkjtykpeqzVzhQjVV1R7fPqnEoEN8YoNY?cluster=devnet

It's been 5 days ago from this case, my sol stuck on buffer address, waiting for 7 days will be too long iguess,  I don't think 0.6 SOL will counted as dumb fee in the mainet 

i just want to see where I can collect this without contacting support manually, but it not available yet.

I suggest to add a feature to claim the amount from buffer address that not used for transactions such as overpayments or in case buyer not press the confirm button or even in case have another issue happened, this feature can be useful and can be integrated with rollback functions for the actions.

Just an idea of the feature


after 1 or 2 hours from last confirmations needed, if not used to exchange, that asset will be shown in profile pages maybe on balance or statistics feature. Only assets that able to be claimed after deducted fees (if needed).

[LoyceV]

Suggestion: when an Offer is Completed, stop auto-refreshing the Deals page every few seconds, this makes it difficult to read the details:

[Bridgoro]

Hey testers,
Hope you are all doing well guys
Tomorrow is the last day of the OPEN BETA, and we will address all recent bug reports and questions then. Right now we are fully focused on the new patch update.

[btcnbegun]

Username bug:

Two different accounts got the same username

My account in test 2


Referral's account participated in Test 1


In fact, it can change into any username who participated in Test1.

[Woodie]

Username bug:

Two different accounts got the same username

My account in test 2


Referral's account participated in Test 1


In fact, it can change into any username who participated in Test1.

Not sure what you mean by "you can change into any username that participated in test1"

For starters, according to Bridgoro on TG the whole database was wiped clean after hotfix patch 1 and that includes accounts that registered in the beta test 1, so any of us trying to take part in beta test 2 are required to re-register

If it's not the case, it would be nice to have steps to replicate this bug 🐛 so that the Bridgoro team can pinpoint this bug:)

[btcnbegun]

Username bug:

Two different accounts got the same username

My account in test 2


Referral's account participated in Test 1


In fact, it can change into any username who participated in Test1.

Username bug(2nd part):

e.g. 'nm9' is accepted as username but '9nm' isn't accepted.

'nm9' sometimes appear Status code 400

[LoyceV]

This is what My Offers looks like now:

This list will quickly become very long. I know there are Filters, but it would be nice if I can click "Hide" on the entries I no longer need to see. This "Hide" feature shouldn't be available on Active Offers, but for Completed (or "rollback completed") Offers.

When one of My Deals is completed, it looks like this:

What I'm missing is my withdrawal data: which address did the withdrawal go to? Especially when creating multiple deals, showing the withdrawal address makes it easier to keep track.

Test: does it work to Cancel an Offer after selling part of it? My 115 XMR > BTC transaction sold 5 XMR, and had about 110 XMR remaining. I clicked Cancel: this worked as expected. I've created a new 100 XMR > BTC offer in case someone wants to test buying them.

Test: what happens if I deposit 30 seconds before "Time Left to Deposit" runs out, and click "Confirm Deposit" 20 seconds before the timer runs out but also before my deposit is confirmed? Result: Deposit timeout. I think this is a concern: if the deposit needs to be confirmed within the hour, many deposits will timeout when on-chain transaction fees rise. I've seen Bitcoin transactions take days or even weeks.

Test: What happens if I send the transaction AFTER clicking "Confirm Deposit"? Deposit timeout.
Is there no way to automate this part? If users have to manually confirm their deposit, I kinda expect that to go wrong quite a lot.

I accepted BTC > XMR Offer ID: 3e413b21-f07f-4ab8-ab39-2bcbf71eb2ef. I sent BTC, and after 1 confirmation I received my XMR!

I tried again:
I accepted BTC > XMR Offer ID: cd94c64f-3456-40c0-a816-99f1631dc4d0. I sent BTC, and with 4 confirmations, it's still "PARTIALLY CONFIRMED" and I haven't received XMR yet. Until now, when I funded My Offers, it would require 7 confirmations for BTC, so I assume that's the case again. But why did the previous Offer need only 1 confirmation?

[Faisal2202]

I am testing the platform again, I know I am late, as today is last day, but I have reasons due to which I was unable to give proper time to this, I just completed reading the bugs reports by members on BTT and I am surprised to see the bugs reported by members in Telegram, they did a great job. Anyway here I might not have to report much as I am late and most of the bugs has already been reported but still checking my luck haha.

1. Dumb Fee term is not defined in the Glossary, as it was added later after masulum pointed out roll back mechanism is not working, so you defined it in the “ how-do-buffer-wallets-work” page but did not add anything about Dumb fee in the Whitepaper’s Glossary and other parts where it should be written and it is also not been updated in the https://bridgoro.gitbook.io/bridgoro-docs/system-architecture/glossary-of-terms page.

2. On the Whitepaper Page, we scroll down the body, like we scroll down from Glossary to the bottom but the TOC (Table of Content) in the right is not moving (syncing) it suppose to move with the body scrolling down, it is not a bug but a UI suggestion, if you like, it feels more sophisticated.

Note: I was checking grammatical and spelling mistakes on the Bridgoro Docs Page and found a few grammatical mistakes that need changes and a lot of suggestions to make the content more sophisticated and trouble-free for you and for the users. I will mention the mistakes that need to be corrected and will gather the suggestions one by one.

3.On the whitepaper page in the last, (System Architecture → Whitepaper → 4.6 Long-Term Vision), a line is written "The roadmap's ultimate trajectory leads toward Brodgoro's self-sustaining ecosystem" The project name is not correct.


4. On the Explore offers page: the first line is correct, but the same line is written on the My offers page in the Docs. As can be seen in the images below, the line should be different like: "On this page, you can view and manage your own exchange offers that you’ve created on Bridgoro."

5. This word is missing an apostrophe, it is necassary as it should be written as "platform’s".


6. Need space here: I know not a major bug but as I defined earlier some grammatical mistakes and contradictions in the whitepaper can cause trouble later even from legal point of view as users might get the wrong idea.


7. The highlighted line in the image below is very troublesome for you, because here you are being good from your perception but if someone copies your code, you might not be able to claim later just because you have said this in your policy as in easy words: it suggests that Bridgoro is not asserting any IP rights over its code, branding, documentation, or design, which directly contradicts the platform’s closed-source and "classified" stance mention below this point. I hope you understand this. It needs to be removed or modified.


8. The highlighted line is very conflicting with the Dumb fee explained just below it. As in the Dumb Fee section, you said

If the transferred funds exceed the required amount, we classify the difference as a Dumb Fee. The exceeding amount remains in the Buffer Wallet until the collector module retrieves it. A user can recover this exceeded Dumb Fee by contacting the support team after a short investigation.

Those two descriptions clash:
One says: extra amount → user gets more, offer recalculated.
The other says: extra amount → treated as Dumb Fee, stays in buffer, only recoverable via support.


9. In the image below, on the Glossary of Terms page, which is dedicated to the terms so writing an incomplete term on this page will conflict with the purpose of its existence. Like in the image, the first heading shows the amount as a dead asset amount but when written in the dead wallet definition, it is written as dead amount instead of dead asset amount.


10. In the "How to start earning" Page, nothing is mentioned. If it is coming soon, then it should be mentioned as well, because not writing anything can confuse the viewer into thinking maybe this page is not reloading on my side, so let's reload it. But in reality, there is nothing there. If it is pending, then add a note there.


So far this was it to report from Docs that need changes and I find them necassary and there are some suggestions which are not that necassary but can sophisticate the content. I am not mentioning them now due to a time issue, sorry.

11. The Table header row is not fixed when we scroll down to the last order, so when we are at the last and confirming the information along the row, we can't know what the data is about like what YES or NO is about so the user has to go all the up to the header row to check the heading of that colume. It's a suggestion that can make the usage more easy if that works for you.

12. While enterning the amount while creating the offer, their should be mentioned how much should I at least chose to avoid the buffer wallet issue, As I tried entering amount two times and I did not get any notification about the amount should be more than X. I just got the notification that the entered amount is less than the dead wallet amount but how much is that is not mentioned a some idea displayed there for a new member is a good choice.

13. QR code integration is also good for those using smartphones for sending funds, nobody wants to waste time on copying and pasting the wallet address here and there, qr code can fasten the process (just a suggestion).

14. On the main page where we explore offers, now unlike before the total pages are four and in all those pages the amount available to open the trade is different like th trade in first place has less available amount and the second has more and the third might have lower the point is, we should be allowed to arrange this columne of available by clicking, like one click all the offers are arranged from higher available amount to lower and another click will reverse that.


15. At the end of the explore offer page where it says "Showing 1 to 20 of 41 offers" Most of the platforms have show lines options like if we want to see 20 lines or 50 line or 100 lines that feature would be great to see all the lines/offers in one go for a person in hurry. Although Filter feature is for them but still it can be helpful.

I created offers and made deals, tested profile, faced no issue like really everything was smooth, due to high number of offers testing the platform was easier. I tested with wrong receiving address, tried to make trade with wrong level offers, tried huge and negative numbers while making deals, tested 2fa, checked notification system and I tested few other things that normally a users will do, but I found no error, no bugs, till now. Everything was working very smooth and sophistically. Great work really appreciatable.

[Bridgoro]

UI/UX overlap and z-index hierarchy problem
On mobile devices, the user profile dropdown menu is overlapping the primary CTA buttons "Start Exchange" and "Start Earn".

Yeah, I see it.
Fun fact: the menu overlaps with the two buttons only on the homepage. We will get that fixed.

Status: [Added to backlog]

Overlay Modal Exceeds Viewport and Overlaps Browser UI
The beta notification modal does not show fully on mobile devices. The title above is not fully visible. A scrollbar needs to be placed here.

The popup size will be adjusted, and its ratio will scale properly based on the screen size.

Status: [Added to backlog]

I'll test this later, December 5 is kids-day here

Family should always come first  

That would make sense, but it's not what happened. See my Rollback Transaction:
The transaction fee was 141 sats, and 311 sats (0.1%) was sent to tb1q7nqts63qz0w8j5k97jwprsupsaxwg8q3j9sndv, which I assume is Bridgoro's address.

Follow-up (a day later): someone took one of my Offers, and sent a payment:

Code:

4789745x8x0    	tb1q52rktesraglsm5kq7wzthshm7v7vy2csxnth22	     0.02000254
4789745x8x1    	tb1qf8zs6nmfxec2ert5rzakkpmnjz9m3d986d0lp2	     0.00000311

Here, there's 311 sats going to another address again. I expected the fee to be a percentage, and I've seen different values for some transactions, but most of them end up sending exactly 311 sats to another address.

Bridgoro is fee-free during testing and will remain fee-free at release.
What you are seeing isn't a fee, it's a UTXO (unspent transaction output).
This behavior is related to Bitcoin's architecture, not to us.
A tiny leftover like 0.00000311 BTC (311 satoshis) appears when:
- The UTXO used as input had a non-rounded value
- The necessary transaction fee was deducted
- The remaining amount wasn't large enough to be useful, but was still above the wallet's dust threshold
- The wallet decided to create a small change UTXO instead of discarding it

TCP Timestamps Information or Session expiry
bridgoro.com
TCP timestamp is enabled (default setting)

Code:

set tcp-option disable    <-- Default value is enable

It was detected that the host implements RFC1323/RFC7323.
The following timestamps were retrieved with a delay of 1 seconds in-between:
Packet 1: 1386648869
Packet 2: 1867871899
There was a delay of 1 seconds in-between packets
This can cause a time-based authentication protocol to lose therefore allowing to compute the uptime

In general, this isn't dangerous.
Knowing system uptime can help attackers:
- Infer reboot times
- Determine whether a system was recently patched
- Coordinate certain blind timing attacks
- Correlate hosts behind NAT or load balancers

But it doesn't provide access, expose credentials, or compromise authentication directly.

The reference to [ time-based authentication ] loss relates to a theoretical weakness in protocols that rely on precise timing, but this isn't a practical attack vector just because of timestamps.

I tried RBF on BTC, while creating an offer to trade BTC for XMR. There's a blockstorm on testnet at the moment, so I only have a few seconds for RBF.
I tried 4 times:
1. Offer ID: fd9a8340-498d-4c69-b74d-64dbe98fb312: RBF failed, the initial transaction confirmed. This Offer is Active.
2. Offer ID: c4f9b59e-0173-4be8-8d00-4d9d26770dd9: RBF succeeded, the initial transaction was replaced. This Offer is stuck as "Partially Confirmed". Interesting detail: I entered amount 0.0006, and sent 0.0006. BUT: My Offer Details now shows Amount to be deposited: 0.00059999. How did this happen?
3. Offer ID: 4d06b394-798a-4938-959e-52d6e90d4b9c: RBF failed, the initial transaction confirmed. BUT: This Offer is stuck as "Partially Confirmed". I think Bridgoro may have picked up on the RBF transaction (the one with higher fee) before it saw the first lower-fee transaction, and got stuck when the low-fee transaction got confirmed. I'm just guessing what happened here.
4. Offer ID: c01e3649-73ba-467f-ab57-dc72ee96780d: RBF succeeded, the initial transaction was replaced. This Offer is stuck as "Partially Confirmed".
I think the RBF implementation needs some work

Appreciate you testing RBF.
We are already investigating the stuck transaction case (because of RBF) and are conducting a deep analysis to determine the proper fix.

Status: [Added to backlog]

Today I decided to complete the tasks again and check the bonus accrual. So far, everything is working as expected. The bonuses have been credited to my account. However, when I click the "Claim" button again, I'm a bit alarmed by the pop-up message in the lower right corner. The idea is really good. It will help keep the audience on the site.

The Claim Task bug was already reported, and we are actively working on it as well.
It will be resolved in our next upcoming patch.

Status: [Already added to backlog]

A good option would be to move this status to a button to avoid confusion for users. It's not very visually convenient to check it in a separate block.

There's no need to move the status field because the Claim Task bug is still present.
Once it's fixed, recurring tasks will show as [Available], and claimed tasks will automatically move to the [Claimed] tab.

It's been 5 days ago from this case, my sol stuck on buffer address, waiting for 7 days will be too long iguess,  I don't think 0.6 SOL will counted as dumb fee in the mainet  
i just want to see where I can collect this without contacting support manually, but it not available yet.
I suggest to add a feature to claim the amount from buffer address that not used for transactions such as overpayments or in case buyer not press the confirm button or even in case have another issue happened, this feature can be useful and can be integrated with rollback functions for the actions.
Just an idea of the feature
after 1 or 2 hours from last confirmations needed, if not used to exchange, that asset will be shown in profile pages maybe on balance or statistics feature. Only assets that able to be claimed after deducted fees (if needed).

Unfortunately, stuck amounts can only be recovered by contacting the support team.
Providing users with direct access to the buffer wallet recovery would introduce new attack vectors. For security reasons, the Buffer Wallet logic follows simple but strict rules.
The Collector Module scans wallets with stuck funds once per week to avoid interfering with active offers.
Dumb Fee remains Dumb Fee. We will introduce a threshold where some Dumb Fee may be returned to the user, but a significant commission will apply since this requires manual processing on our side.

Suggestion: when an Offer is Completed, stop auto-refreshing the Deals page every few seconds, this makes it difficult to read the details:

Yeah, we will fix that as well.

Status: [Added to backlog]

Username bug:
Two different accounts got the same username
My account in test 2
Referral's account participated in Test 1
In fact, it can change into any username who participated in Test1.

It's not a bug.
We wiped the entire database when deploying the hotfix, so all data (including user accounts and usernames) was deleted.

Not sure what you mean by "you can change into any username that participated in test1"
For starters, according to Bridgoro on TG the whole database was wiped clean after hotfix patch 1 and that includes accounts that registered in the beta test 1, so any of us trying to take part in beta test 2 are required to re-register
If it's not the case, it would be nice to have steps to replicate this bug 🐛 so that the Bridgoro team can pinpoint this bug:)

Thanks for helping clarify the user database wipe situation.

Username bug(2nd part):
e.g. 'nm9' is accepted as username but '9nm' isn't accepted.
'nm9' sometimes appear Status code 400

This is a bug.
Thanks for reporting it.

Status: [Added to backlog]

This is what My Offers looks like now:
This list will quickly become very long. I know there are Filters, but it would be nice if I can click "Hide" on the entries I no longer need to see. This "Hide" feature shouldn't be available on Active Offers, but for Completed (or "rollback completed") Offers.

We will implement the feature to hide inactive offers and deals (completed, deposit timeout, aborted) after the release.

When one of My Deals is completed, it looks like this:
What I'm missing is my withdrawal data: which address did the withdrawal go to? Especially when creating multiple deals, showing the withdrawal address makes it easier to keep track.

Press the info icon (i) next to the Deal Details popup header.
We intentionally didn't pack too much data into a single popup to avoid overwhelming the user and shifting the focus.

Test: does it work to Cancel an Offer after selling part of it? My 115 XMR > BTC transaction sold 5 XMR, and had about 110 XMR remaining. I clicked Cancel: this worked as expected. I've created a new 100 XMR > BTC offer in case someone wants to test buying them.

Thanks for testing this feature.

Test: what happens if I deposit 30 seconds before "Time Left to Deposit" runs out, and click "Confirm Deposit" 20 seconds before the timer runs out but also before my deposit is confirmed? Result: Deposit timeout. I think this is a concern: if the deposit needs to be confirmed within the hour, many deposits will timeout when on-chain transaction fees rise. I've seen Bitcoin transactions take days or even weeks.

In most cases, 30 minutes is enough for BTC to receive at least one blockchain confirmation.
I think this part will naturally improve based on user feedback after release if any issues arise.

Test: What happens if I send the transaction AFTER clicking "Confirm Deposit"? Deposit timeout.
Is there no way to automate this part? If users have to manually confirm their deposit, I kinda expect that to go wrong quite a lot.

If a user can't complete two simple steps:
1. Deposit the required funds into the designated buffer wallet, and
2. Press the Confirm Deposit button
 
then this user probably shouldn't be on our platform.

I accepted BTC > XMR Offer ID: 3e413b21-f07f-4ab8-ab39-2bcbf71eb2ef. I sent BTC, and after 1 confirmation I received my XMR!
I tried again:
I accepted BTC > XMR Offer ID: cd94c64f-3456-40c0-a816-99f1631dc4d0. I sent BTC, and with 4 confirmations, it's still "PARTIALLY CONFIRMED" and I haven't received XMR yet. Until now, when I funded My Offers, it would require 7 confirmations for BTC, so I assume that's the case again. But why did the previous Offer need only 1 confirmation?

We will reduce the required BTC confirmations to 2 or 3. I will finalize this with my teammate after we finish fixing the current bugs.

[Bridgoro]

I am testing the platform again, I know I am late, as today is last day, but I have reasons due to which I was unable to give proper time to this, I just completed reading the bugs reports by members on BTT and I am surprised to see the bugs reported by members in Telegram, they did a great job. Anyway here I might not have to report much as I am late and most of the bugs has already been reported but still checking my luck haha.

Hey Faisal,
Thanks for taking the time to test the platform again, even on the last day of the Beta. I will count your bug report, and I will reply tomorrow after we fix the text issues, since most of your findings are related to typos.

[Bridgoro]

You found time to test even on the last day of the BETA, so I decided to make time to respond to your reports while the Beta is still running.

1. Dumb Fee term is not defined in the Glossary, as it was added later after masulum pointed out roll back mechanism is not working, so you defined it in the “ how-do-buffer-wallets-work” page but did not add anything about Dumb fee in the Whitepaper’s Glossary and other parts where it should be written and it is also not been updated in the https://bridgoro.gitbook.io/bridgoro-docs/system-architecture/glossary-of-terms page.

Status: [Fixed]

2. On the Whitepaper Page, we scroll down the body, like we scroll down from Glossary to the bottom but the TOC (Table of Content) in the right is not moving (syncing) it suppose to move with the body scrolling down, it is not a bug but a UI suggestion, if you like, it feels more sophisticated.

GitBook doesn't belong to us.
And if you look closely, the right-side panel moves as you scroll down and even highlights the paragraph you are currently viewing.

Note: I was checking grammatical and spelling mistakes on the Bridgoro Docs Page and found a few grammatical mistakes that need changes and a lot of suggestions to make the content more sophisticated and trouble-free for you and for the users. I will mention the mistakes that need to be corrected and will gather the suggestions one by one.
3.On the whitepaper page in the last, (System Architecture → Whitepaper → 4.6 Long-Term Vision), a line is written "The roadmap's ultimate trajectory leads toward Brodgoro's self-sustaining ecosystem" The project name is not correct.

Status: [Fixed]

4. On the Explore offers page: the first line is correct, but the same line is written on the My offers page in the Docs. As can be seen in the images below, the line should be different like: "On this page, you can view and manage your own exchange offers that you’ve created on Bridgoro."

Status: [Fixed]

5. This word is missing an apostrophe, it is necassary as it should be written as "platform’s".

Status: [Fixed]

6. Need space here: I know not a major bug but as I defined earlier some grammatical mistakes and contradictions in the whitepaper can cause trouble later even from legal point of view as users might get the wrong idea.

Status: [Fixed]

7. The highlighted line in the image below is very troublesome for you, because here you are being good from your perception but if someone copies your code, you might not be able to claim later just because you have said this in your policy as in easy words: it suggests that Bridgoro is not asserting any IP rights over its code, branding, documentation, or design, which directly contradicts the platform’s closed-source and "classified" stance mention below this point. I hope you understand this. It needs to be removed or modified.

We already answered to this question here.
Yes, we are certain that we will not claim ownership.
The reason is simple: once we start claiming ownership, we immediately run into problems because Bridgoro has no KYC or AML policies.

8. The highlighted line is very conflicting with the Dumb fee explained just below it. As in the Dumb Fee section, you said
If the transferred funds exceed the required amount, we classify the difference as a Dumb Fee. The exceeding amount remains in the Buffer Wallet until the collector module retrieves it. A user can recover this exceeded Dumb Fee by contacting the support team after a short investigation.

Dumb Fee applies only to the excess amount during DEAL acceptance. But if you send an excess amount during OFFER creation, your offer will be recalculated instead.
To avoid any double interpretation, I added the following clarification under the sentence you highlighted:
But when sending a larger amount while accepting DEALS (offers created by other users), the excess amount is counted as a DUMB FEE and remains in the Buffer Wallet.

Status: [Fixed]

Those two descriptions clash:
One says: extra amount → user gets more, offer recalculated.
The other says: extra amount → treated as Dumb Fee, stays in buffer, only recoverable via support.

Status: [Fixed]

9. In the image below, on the Glossary of Terms page, which is dedicated to the terms so writing an incomplete term on this page will conflict with the purpose of its existence. Like in the image, the first heading shows the amount as a dead asset amount but when written in the dead wallet definition, it is written as dead amount instead of dead asset amount.

Status: [Fixed]

10. In the "How to start earning" Page, nothing is mentioned. If it is coming soon, then it should be mentioned as well, because not writing anything can confuse the viewer into thinking maybe this page is not reloading on my side, so let's reload it. But in reality, there is nothing there. If it is pending, then add a note there.

Status: [Fixed]

11. The Table header row is not fixed when we scroll down to the last order, so when we are at the last and confirming the information along the row, we can't know what the data is about like what YES or NO is about so the user has to go all the up to the header row to check the heading of that colume. It's a suggestion that can make the usage more easy if that works for you.

We will make the table header sticky, so it stays visible as you scroll down through the content.

Status: [Added to backlog]

12. While enterning the amount while creating the offer, their should be mentioned how much should I at least chose to avoid the buffer wallet issue, As I tried entering amount two times and I did not get any notification about the amount should be more than X. I just got the notification that the entered amount is less than the dead wallet amount but how much is that is not mentioned a some idea displayed there for a new member is a good choice.

We will evaluate how to improve this part after the release.
Thanks for the suggestion.

13. QR code integration is also good for those using smartphones for sending funds, nobody wants to waste time on copying and pasting the wallet address here and there, qr code can fasten the process (just a suggestion).

The QR suggestion was submitted to us during the first Beta, and we will implement it after the release.

14. On the main page where we explore offers, now unlike before the total pages are four and in all those pages the amount available to open the trade is different like th trade in first place has less available amount and the second has more and the third might have lower the point is, we should be allowed to arrange this columne of available by clicking, like one click all the offers are arranged from higher available amount to lower and another click will reverse that.

It will be implemented after the release.

15. At the end of the explore offer page where it says "Showing 1 to 20 of 41 offers" Most of the platforms have show lines options like if we want to see 20 lines or 50 line or 100 lines that feature would be great to see all the lines/offers in one go for a person in hurry. Although Filter feature is for them but still it can be helpful.

This UX feature will be also added after release.

I created offers and made deals, tested profile, faced no issue like really everything was smooth, due to high number of offers testing the platform was easier. I tested with wrong receiving address, tried to make trade with wrong level offers, tried huge and negative numbers while making deals, tested 2fa, checked notification system and I tested few other things that normally a users will do, but I found no error, no bugs, till now. Everything was working very smooth and sophistically. Great work really appreciatable.

Thanks, buddy for putting in the effort to test so many important areas that needed verification. We are glad that in Beta 2 we've seen fewer bugs than in the first round, and the exchange feature is performing much better than it did during the initial Beta. But thanks to LoyceV, we identified several critical issues, and we are actively working on them now.

[LoyceV]

What you are seeing isn't a fee, it's a UTXO (unspent transaction output).
This behavior is related to Bitcoin's architecture, not to us.
A tiny leftover like 0.00000311 BTC (311 satoshis) appears when:
- The UTXO used as input had a non-rounded value
- The necessary transaction fee was deducted
- The remaining amount wasn't large enough to be useful, but was still above the wallet's dust threshold
- The wallet decided to create a small change UTXO instead of discarding it

This sounds like a problem in your implementation. When I take one UTXO (with non-rounded value) and send it to another address, there is no change address necessary. See 9a8e9bbe51c37c229eb5d9922a719af841e99cd3cffe8f6a2986a7f3f4ac0924 for example.
Maybe you're trying to calculate the amount to send by assuming a fee and subtracting it from the total, instead of doing "send all minus fee", as I did in the transaction above.

Press the info icon (i) next to the Deal Details popup header.

Thanks, that's all I was looking for. It's amazing how blind I am to such obvious things.... I really searched for something!

[The Sceptical Chymist]

I'm a bit alarmed by the pop-up message in the lower right corner.

I was alarmed for a different reason; acception isn't even a word that's used anymore.  This isn't trivial, because any native English speaking customers are going to see that and probably jump to a quick conclusion that Bridgoro is another fly-by-night foreign exchange that's trying to attract English speaking traders (for whatever reason) but doesn't know the language themselves.  Exception or acceptance would be what you're going for here.

That's constructive criticism, by the way.  Hopefully I did not misinterpret something, lest I look like the entire rear end of a donkey.

Also, if that RBF option can be abused successfully, you'll have a line of scammers ten thousand long just waiting to rip you off.  I wish you luck and hope something like that doesn't happen.