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

[LoyceV]

Under Explore Offers, I see this:

Under Your Offers, I see this:

Suggestion: can you add a progress indicator? Say: "23% Completed"? I can imagine it becomes harder to keep track when someone creates many offers and they're all partially completed. Even better if the user can sort by the Completed percentage column.

When I create an Offer, I receive confirmation emails that address me as "Dear Seller,". This is correct.
When someone accepts my Offer, I receive several emails with subjects "Deal Release Initiated" and "Deal Completed Successfully". Both emails address me as "Dear Buyer,", which I assume is a bug.

Inside the email:

Code:

-   Input: 100000 BITCOIN_SATOSHI
-   Output: 229872241326 MONERO_PICONERO
-   Status: Completed

Suggestion: switch to more useful units: it's much easier to see the value when you write 0.229872241326 XMR. For Bitcoin, both 0.001 BTC or 100000 sat aren't ideal. Maybe this should depend on the amount being sent: if it's large, use BTC, if it's small, use sats. But considering all of Bridgoro uses the full units, it's probably best to do the same in the confirmation email: use BTC and XMR. Many people are already confused by "milli", I don't think they'll get "pico". Google tells me piconero is cheese.

I'd like to have more informative email headers: if I rely on emails to keep track of the status of my trades, I'd prefer to see which Offer is involved without opening the email, especially since Bridgoro quickly sends many emails. Maybe add the trading pair to the title, or give each one of My Offers a number (a short number, so start at 1) so I can quickly identify which Offer it's about.

I've never before sent such large XMR amounts before, nor used the GUI wallet, nor had that many inputs. When I sent my entire GUI balance at once to Feather, I received 2 transactions: 115 + 53 XMR. That means somehow it was split up into 2 transactions without me asking for it, and I guess that's because of the large number of inputs. If I would have sent that transaction to Bridgoro, and it would have received 2 instead of 1 incoming transaction, would system be able to handle that properly? Since this is an automatic "feature" of Monero's GUI wallet, I think it's kinda important that this is handled correctly. I'll test this after mining another 150+ coins

I can't test this:

Code:

Error
Maximum amount per offer reached for user level

Can you increase my User Level so I can create a test transaction to sell 200 XMR for BTC? I'm user4117083827.

Suggestion: show the maximum amount on the Create Offer page. Now I can only see it when I fill in my addresses and click "Create".

we implemented the simplest and most reliable solution: we treat the exceeding amount as a  [ Dumb Fee ].
This excess amount remains in the Buffer Wallet, and the collector module will collect it if the amount is high enough to cover the network fee. If not, it just stays there. The exceeding amount can still be retrieved by contacting Bridgoro support after a short verification.

I just had to test this:
1. What happens if a buyer sends too much? Let's test: I sent 1 XMR for a 0.034990116953 XMR Offer.
    Result: I paid a huge dumb fee and received the coins I bought as expected.
I kinda like the idea of making the user responsible for their own stupidity But once the site becomes very active, I wouldn't be surprised if Support gets overloaded with refund requests. Yep, I have high confidence in human stupidity.
2. What happens if a user sends too much while creating an Offer? Let's test: I created an offer to trade 1 XMR, and deposited 10 XMR.
    Result: Now this gets interesting: My Offer for 10 XMR is created! Even though Bridgoro told me my user level is too low, I can just deposit more and create it anyway. I expected a 9 XMR "Dump Fee" in this case!
    Follow-up test: Cancel this offer: I get 10 XMR (minus fee) returned.

After clicking Cancel, I found a typo (2x), and I assume this should be "initiated":

Code:

Cancel Rollback Inited
It means the cancel rollback has been inited.

3. Can a Level 0 user create a Level 4 Offer? Let's test: I ticked "LEVEL 4" and sent 50 XMR to create a "1" XMR Offer. Just whale things.
    Result: I, a LEVEL 0 n00b, can create a 50 XMR Offer that's only available for LEVEL 4 users:

I assume this is an unintended "feature", after all, the system tells me I can't even create a 5 XMR Offer.

Now I'm curious to test the opposite of #2:
4. What happens if a user Creates an Offer for 1 XMR, but deposits only 0.9 XMR?
    Result: "Partially confirmed underpayment". Followed by an automated refund (minus transaction fee).
    Question: is this the intended behaviour? Why not still create the offer? I'm asking, because most instant exchanges allow for a slight variation in deposit and adjust the trade accordingly, so many users will be used to not paying attention to exact values.
I think the emails about this can be improved:

Code:

We have detected an underpayment for your offer. The partially confirmed deposit amount is less than the required amount.
~
Please contact support or make an additional deposit to complete your offer.

Followed by:

Code:

Your deposit for offer has been confirmed, but the amount received is less than required.
~
Please make an additional deposit or contact our support team for assistance.

Missing:
<an email telling me I received a refund>
It would make sense if the first (unconfirmed) email tells me to make an addition deposit, but the second email arrives around the time of the refund, so by then it would be more useful to tell me to wait for my refund, and create a new Offer. This is going to suck when Bitcoin transaction fees are high. I suggest to remove the "or contact our support team" from emails related to underpayments.
There should probably be a limit to how many deposits a user can make to fund one Offer: if an abuser would make for instance 1000 dust transactions to fund an Offer, the buyer will see the majority of his buy spent on transaction fees.

In total, I've had to login again 5 times (so far) during my testing, including captcha. This will be a very big no go for real life usage on a private browser.

Today, I only had to log in once and could do all my testing without being kicked out again.

[Bridgoro]

Suggestion: can you add a progress indicator? Say: "23% Completed"? I can imagine it becomes harder to keep track when someone creates many offers and they're all partially completed. Even better if the user can sort by the Completed percentage column.

Very good suggestion!
It's similar to the order-fill percentage indicator on CEX platforms.
We will definitely add this feature, but a bit later, as we are still working through the remaining minor bugs.

Status: [Added to backlog]

When I create an Offer, I receive confirmation emails that address me as "Dear Seller,". This is correct.
When someone accepts my Offer, I receive several emails with subjects "Deal Release Initiated" and "Deal Completed Successfully". Both emails address me as "Dear Buyer,", which I assume is a bug.

This is a bug related to the email logic.
We will fix it soon.

Status: [Added to backlog]

Inside the email:

Code:

-   Input: 100000 BITCOIN_SATOSHI
-   Output: 229872241326 MONERO_PICONERO
-   Status: Completed

Suggestion: switch to more useful units: it's much easier to see the value when you write 0.229872241326 XMR. For Bitcoin, both 0.001 BTC or 100000 sat aren't ideal. Maybe this should depend on the amount being sent: if it's large, use BTC, if it's small, use sats. But considering all of Bridgoro uses the full units, it's probably best to do the same in the confirmation email: use BTC and XMR. Many people are already confused by "milli", I don't think they'll get "pico". Google tells me piconero is cheese.

I understand your frustration, we left it in this form for testing purposes only.
But soon, as we get closer to the end of the Beta, we will switch it to normal human-readable data.

Status: [Not a bug]

I'd like to have more informative email headers: if I rely on emails to keep track of the status of my trades, I'd prefer to see which Offer is involved without opening the email, especially since Bridgoro quickly sends many emails. Maybe add the trading pair to the title, or give each one of My Offers a number (a short number, so start at 1) so I can quickly identify which Offer it's about.

We will add the Offer ID to the notification emails along with the rest of the data.

Status: [Added to backlog]

Code:

Error
Maximum amount per offer reached for user level

Can you increase my User Level so I can create a test transaction to sell 200 XMR for BTC? I'm user4117083827.
Suggestion: show the maximum amount on the Create Offer page. Now I can only see it when I fill in my addresses and click "Create".

Please accept the task on the Earnings page titled [ Task for LV4 (Bitcointalk) ]
and submit the code I sent you via PM.
Once your submission is approved, you will receive enough XP to upgrade to a Level 4 account.

And your suggestion noted.
Status: [Added to backlog]

1. What happens if a buyer sends too much? Let's test: I sent 1 XMR for a 0.034990116953 XMR Offer.
    Result: I paid a huge dumb fee and received the coins I bought as expected.
I kinda like the idea of making the user responsible for their own stupidity But once the site becomes very active, I wouldn't be surprised if Support gets overloaded with refund requests. Yep, I have high confidence in human stupidity.

That's exactly why we named that fee the Dumb Fee.

2. What happens if a user sends too much while creating an Offer? Let's test: I created an offer to trade 1 XMR, and deposited 10 XMR.
    Result: Now this gets interesting: My Offer for 10 XMR is created! Even though Bridgoro told me my user level is too low, I can just deposit more and create it anyway. I expected a 9 XMR "Dump Fee" in this case!
    Follow-up test: Cancel this offer: I get 10 XMR (minus fee) returned.

This isn't a bug, but it seems we missed this part, and now a Level 0 account can create an Exchange Offer using any amount, essentially an exploit.
We will fix this or come up with a new idea to prevent such amount increases.

Status: [Added to backlog]

After clicking Cancel, I found a typo (2x), and I assume this should be "initiated":

Code:

Cancel Rollback Inited
It means the cancel rollback has been inited.

"Inited" is the past tense and past participle of the verb "init" which is used in computing to mean "initialized".

3. Can a Level 0 user create a Level 4 Offer? Let's test: I ticked "LEVEL 4" and sent 50 XMR to create a "1" XMR Offer. Just whale things.
    Result: I, a LEVEL 0 n00b, can create a 50 XMR Offer that's only available for LEVEL 4 users:
I assume this is an unintended "feature", after all, the system tells me I can't even create a 5 XMR Offer.

We already responded above, and we will fix this part.

Status: [Already added to backlog]

Now I'm curious to test the opposite of #2:
4. What happens if a user Creates and Offer for 1 XMR, but deposits only 0.9 XMR?
    Result: "Partially confirmed underpayment". Followed by an automated refund (minus transaction fee).
    Question: is this the intended behaviour? Why not still create the offer? I'm asking, because most instant exchanges allow for a slight variation in deposit and adjust the trade accordingly, so many users will be used to not paying attention to exact values.

Yes, this intended behaviour and the same must be when you send exceeding amount when you create offer.

Status: [Not a bug]

I think the emails about this can be improved:

Code:

We have detected an underpayment for your offer. The partially confirmed deposit amount is less than the required amount.
~
Please contact support or make an additional deposit to complete your offer.

Followed by:

Code:

Your deposit for offer has been confirmed, but the amount received is less than required.
~
Please make an additional deposit or contact our support team for assistance.

Missing:
<an email telling me I received a refund>
It would make sense if the first (unconfirmed) email tells me to make an addition deposit, but the second email arrives around the time of the refund, so by then it would be more useful to tell me to wait for my refund, and create a new Offer. This is going to suck when Bitcoin transaction fees are high. I suggest to remove the "or contact our support team" from emails related to underpayments.
There should probably be a limit to how many deposits a user can make to fund one Offer: if an abuser would make for instance 1000 dust transactions to fund an Offer, the buyer will see the majority of his buy spent on transaction fees.

Its a bug and we will fix it soon.

Status: [Already added to backlog]

Today, I only had to log in once and could do all my testing without being kicked out again.

Session Expiration bug is still exists and we are working on fixing it and temporary turned of in some scenarios.
We will notify all users when session expiration will work correctly.

Status: [In progress]

[btcnbegun]

We aren't hiding the fact that we use Cloudflare.
Since we don't have a large budget for advanced security infrastructure, we rely on Cloudflare and we don't see anything wrong with that. Recently, Cloudflare had an outage and almost 90% of websites went down, which shows how many major companies use it as well.

All the scanned ports don't belong to our servers but they all belong to Cloudflare. The same applies to the IP address.
I checked our server IPs again, and I can confirm that 104.21.27.207 belongs to Cloudflare, not to us.

All traffic to Bridgoro is routed through Cloudflare's network rather than directly to our origin server. This protects our real server IP from attackers and allows Cloudflare to filter malicious traffic before it ever reaches you.

Summary:
Thanks for searching for security vulnerabilities and scanning ports, but your findings did not expose any of our ports or IP addresses.

How Cloudflare works

Cloudflare post hack analysis is most gruesome. 'Latent bug' is, it is called can only be discovered after the application has been released.

Security research claims that IP address

Code:

199.192.16.83

and Namecheap.com. While Namecheap is the the best provider, one might start looking for cloudflare alternatives.

Bitcoin port 8333 looks secured



Could you specify where if JAVA is running?


A security regression (CVE-2006-5051) was discovered:

TCP: 80 443

Description: ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. A MiTM attacker having access to victim's traffic at the TCP/IP layer can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.

A security regression was discovered:

TCP 22

Description:
A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.

A security issue in nginx resolver was identified:

CVE-2021-23017

TCP 80 443

Description:
A security issue in nginx resolver was identified, which might allow an attacker who is able to forge UDP packets from the DNS server to cause 1-byte memory overwrite, resulting in worker process crash or potential other impact.

TCP 22

Description:
In ssh-agent in OpenSSH before 9.6, certain destination constraints can be incompletely applied. When destination constraints are specified during addition of PKCS#11-hosted private keys, these constraints are only applied to the first key, even if a PKCS#11 token returns multiple keys.

TCP 80 443

Description:
The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.

[apogio]

Hello!

1. I'm in the middle of trying the website. I'll update this post.
2. I didn't have the time to fully read the thread, so excuse me if you've answered some of the suggestions. Just ignore them if they're duplicates.


Transaction Status

I don't know if it's just me, but those 2 indications confuze me. Would it be possible to add another circle in the progress bar? Something like "Waiting Confirmation"? I know it's written with small letters below, but it's like the deposit action isn't finished, although it's finished already.




Refresh Deals Button

I think this button should have a small UI component, a gif or something, to show that it does something when you click it. When I click it, it isn't obvious to the user that it actually triggers something.




Menu

I would remove those menu options since they are already visible in the navbar.

[Bridgoro]

Cloudflare post hack analysis is most gruesome. 'Latent bug' is, it is called can only be discovered after the application has been released.
Security research claims that IP address

Code:

199.192.16.83

and Namecheap.com. While Namecheap is the the best provider, one might start looking for cloudflare alternatives.

This IP: 199.192.16.83 doesn't belong to our primary and secondary servers.

Bitcoin port 8333 looks secured
Could you specify where if JAVA is running?

All non-sensitive information is already included in our Whitepaper. Any remaining details are confidential and cannot be disclosed at this stage.

A security regression (CVE-2006-5051) was discovered:
TCP: 80 443
Description: ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. A MiTM attacker having access to victim's traffic at the TCP/IP layer can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.
A security regression was discovered:
TCP 22
Description:
A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.
A security issue in nginx resolver was identified:
CVE-2021-23017
TCP 80 443
Description:
A security issue in nginx resolver was identified, which might allow an attacker who is able to forge UDP packets from the DNS server to cause 1-byte memory overwrite, resulting in worker process crash or potential other impact.
TCP 22
Description:
In ssh-agent in OpenSSH before 9.6, certain destination constraints can be incompletely applied. When destination constraints are specified during addition of PKCS#11-hosted private keys, these constraints are only applied to the first key, even if a PKCS#11 token returns multiple keys.
TCP 80 443
Description:
The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.

Thanks for checking the vulnerability. At this stage, without actual exploitation results, we can't implement every possible security measure, because doing so would lead to endless hardening efforts on a project that hasn't launched yet.
We appreciate your research, and we will review it later in the development timeline. Any necessary components will be corrected and implemented accordingly.

Transaction Status
I don't know if it's just me, but those 2 indications confuze me. Would it be possible to add another circle in the progress bar? Something like "Waiting Confirmation"? I know it's written with small letters below, but it's like the deposit action isn't finished, although it's finished already.

Thank you for joining Beta.
I really don't get the issue here, because everything is already written clearly.
Unfortunately, we can't implement every user suggestion, especially when it comes down to individual preferences or personal taste.
In this case, we've chosen the version that delivers the clearest and most practical user experience.
When a user confirms that funds were deposited, the system moves to the next step called DEPOSIT. The interface also displays an explanation stating that the transaction was confirmed by the user but not yet by the blockchain, which is why the system is waiting for blockchain confirmation of the action.

Suggestion [denied]

Refresh Deals Button
I think this button should have a small UI component, a gif or something, to show that it does something when you click it. When I click it, it isn't obvious to the user that it actually triggers something.

When you click the REFRESH button, the entire table is updated immediately. There's no need to add an animation because the refresh process takes less than a second. If the operation hangs due to a slow internet connection, the user will receive a popup error indicating network issues.

Suggestion [denied]

Menu
I would remove those menu options since they are already visible in the navbar.

If we remove the menu options, mobile users won't be able to switch between pages, so the navigation has to remain in place. Please test it on your mobile device to confirm.
For desktop users, we kept the menu at the top to maintain easy and comfortable navigation across all sections.

Suggestion [denied]

[LoyceV]

I'd like to have more informative email headers: if I rely on emails to keep track of the status of my trades, I'd prefer to see which Offer is involved without opening the email, especially since Bridgoro quickly sends many emails. Maybe add the trading pair to the title, or give each one of My Offers a number (a short number, so start at 1) so I can quickly identify which Offer it's about.

We will add the Offer ID to the notification emails along with the rest of the data.

The Offer ID (like "2530f84d-a5f6-4edb-83ca-a86bb6a39ef1") doesn't tell me anything without looking it up I was hoping for something I can easily recognize, so instead of a long Offer ID, a simple counter that counts my own offers (hence starting at 1).

"Inited" is the past tense and past participle of the verb "init" which is used in computing to mean "initialized".

Note to self: leave the language details to the natives

Can you increase my User Level so I can create a test transaction to sell 200 XMR for BTC?

~ you will receive enough XP to upgrade to a Level 4 account.

Thanks, I'm LEVEL 4 now. Let's test what happens if I deposit 250 XMR from Monero GUI Wallet, which I mined in chunks of about 0.7925 XMR each. When I send 250 XMR (in 1 transaction), my wallet splits it into 3 transactions:


Unfortunately, Bridgoro only picks up one deposit:

I did not receive an "Offer Underpaid" email.

Considering Bridgoro didn't pick up on the full amount, I expected it to return the 115.093352523206 XMR (based on the following quote), but that didn't happen:

4. What happens if a user Creates and Offer for 1 XMR, but deposits only 0.9 XMR?
    Result: "Partially confirmed underpayment". Followed by an automated refund (minus transaction fee).
    Question: is this the intended behaviour?

Yes, this intended behaviour

My offer for 115.09~ XMR is now available on Bridgoro. This looks like a bug: when it's fixed, I can test it again.

[Bridgoro]

Thanks, I'm LEVEL 4 now. Let's test what happens if I deposit 250 XMR from Monero GUI Wallet, which I mined in chunks of about 0.7925 XMR each. When I send 250 XMR (in 1 transaction), my wallet splits it into 3 transactions:
Unfortunately, Bridgoro only picks up one deposit:
I did not receive an "Offer Underpaid" email.
Considering Bridgoro didn't pick up on the full amount, I expected it to return the 115.093352523206 XMR (based on the following quote), but that didn't happen:
My offer for 115.09~ XMR is now available on Bridgoro. This looks like a bug: when it's fixed, I can test it again.

LoyceV, you did a great job testing this issue!
Otherwise, we would have never known that such transaction splitting could occur.
I clearly see the problem now, and we need some time to conduct our own investigation on this side.
We will definitely share the results of our research and report back to everyone here once it’s completed.

[fruktik]

Hello. I looked at the page's code and found a "code status" error.






How serious is this? I can't guess, but as far as I know, it shouldn't happen, right?





A great opportunity for those who don't want to go through the identity verification process. I've been looking for something like this for a long time. Thank you.

[Bridgoro]

Hello. I looked at the page's code and found a "code status" error.
How serious is this? I can't guess, but as far as I know, it shouldn't happen, right?

Thank you for joining the Beta.
You can safely ignore these errors they relate to page indexing and formatting inconsistencies detected by indexing engines. These issues have no impact on system stability or functionality.

[fruktik]

When requesting a withdrawal, this error appears. As I understand it, this feature is not available at the moment, right?



I looked at the project roadmap. Everything seems to be going according to plan so far.



Although this is not so critical and is essentially a mere trifle, it is advisable to specify an acceptable size value for the avatar.




A great option would be the following implementation: a pop-up menu with crypto deposits.

[btcnbegun]

Bitcoin port 8333 looks secured
Could you specify where if JAVA is running?

All non-sensitive information is already included in our Whitepaper. Any remaining details are confidential and cannot be disclosed at this stage.

Vulnerable JS Library
https://bridgoro.com/assets/index.24a38bbe.js

Code:

@license DOMPurify 2.3.3 | (c) Cure53 and other contributors | Released under the Apache license 2.0 and Mozilla Public License 2.0 | github.com/cure53/DOMPurify/blob/2.3.3/LICENSE */function aar(e){if(Array.isArray(e)){for(var t=0,r=Array(e.length);t<e.length;t++)r[t]=e[t];return r}else return Array.from(e)}var

Current version : DOMPurify, version 3.3



CSP Header Not Set
https://bridgoro.com

Code:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google.com https://www.gstatic.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://www.google.com https://*.etherscan.io https://*.solscan.io https://*.tronscan.org https://mempool.space https://stagenet.xmrchain.net https://blockchair.com https://moneroblocks.info https://shasta.tronscan.org https://bridgoro.gitbook.io; font-src 'self'; frame-src https://www.google.com https://www.gstatic.com; form-action 'self'; base-uri 'self'; object-src 'none'" />-->

the img-src directive is set to 'self' bridgoro.com.
Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

[NotATether]

I just checked the Devtools Console, you might not want to print auth information like this with console.log().

The access token and the refresh token are also printed. This JWT value allows an attacker to impersonate a logged-in user, in this case, my account, by saving it in localstorage.

Code:

index.24a38bbe.js:154 {screen: 'LOGIN', access_token: '', refresh_token: '', login: '', captcha_token: '', …}access_token: ""authorized: falsecaptcha_token: ""code: ""errors: []first_screen: "LOGIN"invite_code: ""is_admin: falseis_signed_in_as_user: falseloading: falselogin: ""refresh_token: ""remember_me: falsescreen: "LOGIN"two_fa_code: ""user_uuid: ""[[Prototype]]: Object

Code:

{screen: 'REGISTER', access_token: '', refresh_token: '', login: 'bridgoro.e6ce1@passmail.net', captcha_token: '0cAFcWeA4ZhBqrbIgIuzz3RoNjiwaQojIzjLe4j07cmQ0XMR89…G5XxbCziDpaYfMzs36PB-mEtGRSqGnnojjxI3aa3iFVI-H2hk', …}
access_token
: 
""
authorized
: 
false
captcha_token
: 
"0cAFcWeA4ZhBqrbIgIuzz3RoNjiwaQojIzjLe4j07cmQ0XMR89-QMhY75LDfFHutlI_GNRwczmFUAn2V2b4CGfWoXkbPx4ehni4yYNwmNOYOYF5ippuJzc3Z3rWONH4zyBryYXF6Sp5xUeoD5GXRd0Hk1vUX_j3mD74XsACb0H3nbZF-i_qzPTiZFh1Mhav1663PTmtiOOz_7FgkWpS-cn5sXjW7g2Z0rC_s9COWISkTmASBxzNugVmSWx1s-S8L2AvviKttrvNd4scN1lS0HNpctQiLcduycGBFFpVBOGC0QDwMSRK2d3uuI35T-eNqYgXn3g0RYNaVZUB-uU0JhpxJfnmmhOcgyDP4eyIJtYhnXkz0jKr_6arQa0Tfa8VtkkSzbgbvyhVOQ0gtY2bqY-IJoIo9Xz2xXrpwMq_f9JH3UIH5wfs5CQ9vN_wr2XoCcQQLbeH9c6NvoA0-Yd_Os6KbyfTcSrL5MsJ4jmUd8kIauB8N55FwZwQ1qc0vQ0_QaYO1JNaPeE0NYZxUVjUJ5j5zKufISdtO2Saoj0jKgKUHSrxHCgaNOlwsT67RrOwu71myWIOPYy_YGzbmDwa4hZ7W5gMNccWGHVJQeuwPB_7muyx8lUg64I549Xv9ZAXdbWGjaCavFK-9LNhTQVFZeUrRywZR-ANrCZT_l_SewMBw2DhJ7y_Yb-JCOp2OvdWHMZtk21f2st-P_6jBJalF6Ey0Tp65TwgjvLhunD1yVgsc12TDkjWaqd71SJ8t1N8gcSer8kbCWxTxIc5_3wcBQtMuyljGpunoGmIOZ3aDXoICuJTHGUq85SIsRTVFHXD5hccIm16GNCu-CPUBIlGw7NeGl1dNlbx-IsHbVUh9mFg3ZocINRhMs0NHwCi1q6bqVlGlsRGNMUKh9hHZtg_s_Z89mW7KPw2VxOra5YIoyhrcpswQ6fnixsKqso1FVzgkvMf8zS2TmM06kPakmYnQ_Kg4bJMD6yQDhpPjWZHvUvb7Vhu9cgdCoILUnOsZi-VuYyY2qZTR02iisyOoa5n8G7HlNO5FrZczS-eJjc9zmUVKeO5mduc6JFeGDt2WoJ0mp6qSsX3QI-2mGQDwa9M3mmYD6Orw6y58eySrNgFfQ7mAsylnMtNLuta417ts_oqAf1ZRXQSEBlCSn_5TlPI2ms_I1nlzxly8DXX2po7kKbrEPyT0uRzL3BjRw8A9R75XAjc-XqODhhZimWexKxoCFICG_Bih-XXgkkKFaDSo4pC6hs5UV3CZD3cIgnNgfeY1HoJLz4nWhOYIzxwyu-VTmDvh82w2B33xZ6vBzJtWaF6fPWqRnQHuhD2TDXhA6ImN-nuBkReWEivZ3sFh5sh1YeUWsDLQEBBASMGS2739evRE77yffPH3zMpPeIiSob9km3e4IXpcZD0H2bgGtg0QFvGU2AQ-zuvtOcVkldDNiNNgDS7u48f0HjdRZFgqXEscpxdF6ytITYRrfXtsKIZ8ZXvNi0DtDV7_EvzDvVTFMdxQC_ZBpQmWIqobhNpg-9UVve_O7eZ1mEjYC7nheeisGHWr86v3C8_0cbQxd2OuYuziWF3bdZto4SviLU-afDq4Fusd-ApVIKzp3zqncGiegEq0inLSvGt-zNsjAeYg-vHW549lW2dStIcpJuBMi8U4fn8XLOHCq77FZkJ0PZ-XCF3-3KFcTxCh05WmLDjN9Prj2aiQVkMu8MbXPB2rnjtoIUgx5ohqG5XxbCziDpaYfMzs36PB-mEtGRSqGnnojjxI3aa3iFVI-H2hk"
code
: 
""
errors
: 
[]
first_screen
: 
"REGISTER"
invite_code
: 
""
is_admin
: 
false
is_signed_in_as_user
: 
false
loading
: 
false
login
: 
"bridgoro.e6ce1@passmail.net"
refresh_token
: 
""
remember_me
: 
false
screen
: 
"REGISTER"
two_fa_code
: 
""
user_uuid
: 
""
[[Prototype]]
: 
Object

Code:

{screen: 'REGISTER_CONFIRM_CODE', access_token: '', refresh_token: '', login: 'bridgoro.e6ce1@passmail.net', captcha_token: '0cAFcWeA4ZhBqrbIgIuzz3RoNjiwaQojIzjLe4j07cmQ0XMR89…G5XxbCziDpaYfMzs36PB-mEtGRSqGnnojjxI3aa3iFVI-H2hk', …}
access_token
: 
""
authorized
: 
false
captcha_token
: 
"0cAFcWeA4ZhBqrbIgIuzz3RoNjiwaQojIzjLe4j07cmQ0XMR89-QMhY75LDfFHutlI_GNRwczmFUAn2V2b4CGfWoXkbPx4ehni4yYNwmNOYOYF5ippuJzc3Z3rWONH4zyBryYXF6Sp5xUeoD5GXRd0Hk1vUX_j3mD74XsACb0H3nbZF-i_qzPTiZFh1Mhav1663PTmtiOOz_7FgkWpS-cn5sXjW7g2Z0rC_s9COWISkTmASBxzNugVmSWx1s-S8L2AvviKttrvNd4scN1lS0HNpctQiLcduycGBFFpVBOGC0QDwMSRK2d3uuI35T-eNqYgXn3g0RYNaVZUB-uU0JhpxJfnmmhOcgyDP4eyIJtYhnXkz0jKr_6arQa0Tfa8VtkkSzbgbvyhVOQ0gtY2bqY-IJoIo9Xz2xXrpwMq_f9JH3UIH5wfs5CQ9vN_wr2XoCcQQLbeH9c6NvoA0-Yd_Os6KbyfTcSrL5MsJ4jmUd8kIauB8N55FwZwQ1qc0vQ0_QaYO1JNaPeE0NYZxUVjUJ5j5zKufISdtO2Saoj0jKgKUHSrxHCgaNOlwsT67RrOwu71myWIOPYy_YGzbmDwa4hZ7W5gMNccWGHVJQeuwPB_7muyx8lUg64I549Xv9ZAXdbWGjaCavFK-9LNhTQVFZeUrRywZR-ANrCZT_l_SewMBw2DhJ7y_Yb-JCOp2OvdWHMZtk21f2st-P_6jBJalF6Ey0Tp65TwgjvLhunD1yVgsc12TDkjWaqd71SJ8t1N8gcSer8kbCWxTxIc5_3wcBQtMuyljGpunoGmIOZ3aDXoICuJTHGUq85SIsRTVFHXD5hccIm16GNCu-CPUBIlGw7NeGl1dNlbx-IsHbVUh9mFg3ZocINRhMs0NHwCi1q6bqVlGlsRGNMUKh9hHZtg_s_Z89mW7KPw2VxOra5YIoyhrcpswQ6fnixsKqso1FVzgkvMf8zS2TmM06kPakmYnQ_Kg4bJMD6yQDhpPjWZHvUvb7Vhu9cgdCoILUnOsZi-VuYyY2qZTR02iisyOoa5n8G7HlNO5FrZczS-eJjc9zmUVKeO5mduc6JFeGDt2WoJ0mp6qSsX3QI-2mGQDwa9M3mmYD6Orw6y58eySrNgFfQ7mAsylnMtNLuta417ts_oqAf1ZRXQSEBlCSn_5TlPI2ms_I1nlzxly8DXX2po7kKbrEPyT0uRzL3BjRw8A9R75XAjc-XqODhhZimWexKxoCFICG_Bih-XXgkkKFaDSo4pC6hs5UV3CZD3cIgnNgfeY1HoJLz4nWhOYIzxwyu-VTmDvh82w2B33xZ6vBzJtWaF6fPWqRnQHuhD2TDXhA6ImN-nuBkReWEivZ3sFh5sh1YeUWsDLQEBBASMGS2739evRE77yffPH3zMpPeIiSob9km3e4IXpcZD0H2bgGtg0QFvGU2AQ-zuvtOcVkldDNiNNgDS7u48f0HjdRZFgqXEscpxdF6ytITYRrfXtsKIZ8ZXvNi0DtDV7_EvzDvVTFMdxQC_ZBpQmWIqobhNpg-9UVve_O7eZ1mEjYC7nheeisGHWr86v3C8_0cbQxd2OuYuziWF3bdZto4SviLU-afDq4Fusd-ApVIKzp3zqncGiegEq0inLSvGt-zNsjAeYg-vHW549lW2dStIcpJuBMi8U4fn8XLOHCq77FZkJ0PZ-XCF3-3KFcTxCh05WmLDjN9Prj2aiQVkMu8MbXPB2rnjtoIUgx5ohqG5XxbCziDpaYfMzs36PB-mEtGRSqGnnojjxI3aa3iFVI-H2hk"
code
: 
"520603"
errors
: 
[]
first_screen
: 
"REGISTER"
invite_code
: 
""
is_admin
: 
false
is_signed_in_as_user
: 
false
loading
: 
false
login
: 
"bridgoro.e6ce1@passmail.net"
refresh_token
: 
""
remember_me
: 
false
screen
: 
"REGISTER_CONFIRM_CODE"
two_fa_code
: 
""
user_uuid
: 
""
[[Prototype]]
: 
Object

Code:

{screen: 'AUTHENTICATED', access_token: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkI…yMDN9.IFEc73K1llhx0Dq89MUGtaWAVjBmN_1j25Irqt7-yrc', refresh_token: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkI…yMDN9.IFEc73K1llhx0Dq89MUGtaWAVjBmN_1j25Irqt7-yrc', login: 'bridgoro.e6ce1@passmail.net', captcha_token: '', …}
access_token
: 
"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoiM2QxNDZlMmItZGE1Ni00MmVmLTk1N2EtMDQyY2Q1YjIwMzY0IiwiZ3JvdXBzIjpbXSwic3ViIjoiQnJpZGdvcm8iLCJleHAiOjE3NjUwOTAyMDN9.IFEc73K1llhx0Dq89MUGtaWAVjBmN_1j25Irqt7-yrc"
authorized
: 
true
captcha_token
: 
""
code
: 
""
errors
: 
[]
first_screen
: 
"LOGIN"
invite_code
: 
""
is_admin
: 
false
is_signed_in_as_user
: 
false
loading
: 
false
login
: 
"bridgoro.e6ce1@passmail.net"
refresh_token
: 
"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoiM2QxNDZlMmItZGE1Ni00MmVmLTk1N2EtMDQyY2Q1YjIwMzY0IiwiZ3JvdXBzIjpbXSwic3ViIjoiQnJpZGdvcm8iLCJleHAiOjE3NjUwOTAyMDN9.IFEc73K1llhx0Dq89MUGtaWAVjBmN_1j25Irqt7-yrc"
remember_me
: 
false
screen
: 
"AUTHENTICATED"
two_fa_code
: 
""
user_uuid
: 
"3d146e2b-da56-42ef-957a-042cd5b20364"
[[Prototype]]
: 
Object

Here are the contents of the script. Maybe you can identify the source ReactJS file based on that.

Code:

let tr = Fa;
jt(tr, "state", hr),
jt(tr, "api", new Pre(gu,"/auth")),
jt(tr, "bridge_core_api", new pk(gu,"/xmrbridge_core")),
jt(tr, "init", async t => {
    await ly.init(),
    hr.setKey("loading", !0),
    t && (Fa.api = t),
    hr.setKey("screen", "LOADING");
    const {access_token: r, refresh_token: n, login: s, invite_code: i} = ly.get_store();
    if (hr.set({
        ...hr.get(),
        ...H9.omitBy({
            access_token: r,
            refresh_token: n,
            login: s,
            invite_code: i
        }, H9.isUndefined)
    }),
    Fa.check_admin(r),
    Fa.check_is_sign_in_as_user(),
    r && n) {
        try {
            await Fa.api.check_auth(),
            hr.setKey("authorized", !0)
        } catch (u) {
            console.log("Auth error", u);
            try {
                if (Fa.should_logout_due_to_remember_me()) {
                    console.log("Logging out due to remember me flag"),
                    Fa.sign_out();
                    return
                }
                const c = await Fa.api.jwt_refresh({
                    refresh_token: n
                });
                Fa.set_tokens(c)
            } catch {
                Fa.sign_out();
                return
            }
        }
        await Fa.auth_success()
    } else
        hr.setKey("screen", hr.get().first_screen || "LOGIN");
    hr.setKey("loading", !1);
    let a = !1;
    const o = () => {
        if (Fa.should_logout_due_to_remember_me() && !a) {
            a = !0,
            localStorage.removeItem("auth"),
            localStorage.removeItem("remember_me"),
            console.log("Logging out due to remember me flag"),
            gs.fire({
                title: "Session Expired",
                text: "Your session has ended. Please log in again to continue.",
                icon: "warning",
                confirmButtonText: "Log In",
                allowOutsideClick: !1,
                allowEscapeKey: !1
            }).then( () => {
                a = !1,
                window.location.href = "/login"
            }
            );
            return
        }
    }
    ;
    setInterval( () => {
        o()
    }
    , 1 * 60 * 1e3),
    o(),
    console.log(Fa.state.value)  // <--- remove this line, in fact remove all console.log() lines in your code.
}

[Woodie]

I just checked the Devtools Console, you might not want to print auth information like this with console.log().

~snip~

Only wish all the feedback from telegram was easily accessible here, and this token abuse was brought in the chat and you can see it if you are interested>>> https://t.me/bridgoro_beta/497

And Bridgoro support said sensitive  information isn't contained besides an email address that can be  seen..."
Also, please keep in mind that the JWT is stored only on your device. If someone gains access to a user's device, then the security responsibility lies on the user's side."

https://t.me/bridgoro_beta/498

[Bridgoro]

When requesting a withdrawal, this error appears. As I understand it, this feature is not available at the moment, right?
I looked at the project roadmap. Everything seems to be going according to plan so far.

Hey buddy, you entered the wrong USDT address.
Check the address field text, it clearly states that only USDT TRC wallets are valid. TRC refers specifically to Tether (USDT) on the Tron network.
We appreciate your testing efforts, but please read the information on the page carefully before submitting reports. If you have any questions, you can also refer to our GitBook Glossary page.

Although this is not so critical and is essentially a mere trifle, it is advisable to specify an acceptable size value for the avatar.

This is a good point.
We will add text describing the allowed Avatar parameters that can be uploaded. Thanks for the suggestion.

A great option would be the following implementation: a pop-up menu with crypto deposits.

We don't have an account-based wallet system, so we believe this feature doesn't bring value in our case.
For your information: you only deposit when you create or accept an Exchange Offer, and during the acceptance process you select the specific asset.

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.

I just checked the Devtools Console, you might not want to print auth information like this with console.log().
The access token and the refresh token are also printed. This JWT value allows an attacker to impersonate a logged-in user, in this case, my account, by saving it in localstorage.

Hey NotATether, glad to see you in our open beta.
Thanks for sharing this issue. We have already been working on it since we received a report about the JWT topic on Telegram.
We need some time to evaluate and decide on alternative token approaches for securely storing user-related information.

Only wish all the feedback from telegram was easily accessible here, and this token abuse was brought in the chat and you can see it if you are interested>>> https://t.me/bridgoro_beta/497
And Bridgoro support said sensitive  information isn't contained besides an email address that can be  seen..."
Also, please keep in mind that the JWT is stored only on your device. If someone gains access to a user's device, then the security responsibility lies on the user's side."
https://t.me/bridgoro_beta/498

Hey Woodie, appreciate your help in this thread.
Sometimes we simply don't have enough free time to point out that certain bug reports were already submitted and are currently being worked on. We also can't repost every Telegram report here, because it would clutter the thread and make it harder for everyone to follow the actual updates.


A few words about security system

Some users have sent us excellent security recommendations, and we will definitely take them into account either in upcoming updates or in future releases after the project goes live.
To be clear: we can't implement every suggestion right now, otherwise the project would remain stuck in Beta and could be improved endlessly. However, we will address the most critical issues before launch.

Recently, my teammate and I discussed what would happen if bad actors somehow gained access to a user's account.
The worst-case scenario is that they could cancel the user's active Exchange Offers but the funds from those canceled trades would still be returned to the account owner's wallet. That's because the return address cannot be changed once an Exchange Offer is created.

They could also attempt to withdraw accumulated BRGX internal tokens but withdrawals require 2FA. Without 2FA enabled, withdrawal is impossible. Even if attackers change the email address, the 2FA remains linked to the account and cannot be removed.
So please remember to back up your 2FA codes.

As you can see, even though we aren't security specialists, we have still implemented a protective mechanism.

[examplens]

Recently, my teammate and I discussed what would happen if bad actors somehow gained access to a user's account.
The worst-case scenario is that they could cancel the user's active Exchange Offers but the funds from those canceled trades would still be returned to the account owner's wallet. That's because the return address cannot be changed once an Exchange Offer is created.

I haven't tested it, so if this has already been discussed, just ignore my comment.
For a refund, it must be possible to add another address, not the same one from which the coins were sent. Users will often send a deposit to Bridgoro directly from another exchange, where it is most often an operational hot wallet, and the refund to such an address will not end up with a specific user.

[LoyceV]

I haven't tested it

Let's test:
When selling Monero, it asks for a "Monero Rollback Address". But when selling Bitcoin, it doesn't ask for a return address.
I've created a new Order, and sent (test) Bitcoin from these addresses:

Code:

4783615x18x0   	tb1q6hlep3yytgv6q0dl8uuj932y9hvhwnqqzvhza5	     0.00031652
4783799x37x0   	tb1qxjlzu5vsgudzhrl7fzfngm604cntwjt848lwkr	     0.00100239
4783604x18x1   	tb1qy2pjce6er89ruymwcp25xyggw8pz623z54xgvh	     0.00149947
4783801x31x0   	tb1qt0e3gd4zzm5zxtu0taathmnr0efpjhy8m2kn3j	     0.00022149
4783604x4x0    	tb1qqd2zx6lcfd98pnpzn5drls780s2s46x6sxek7s	     0.00014469

For a refund, it must be possible to add another address, not the same one from which the coins were sent.

I'll see what happens when I Cancel my transaction when it's confirmed (which will probably take 2 hours).

[Bridgoro]

Thanks, I'm LEVEL 4 now. Let's test what happens if I deposit 250 XMR from Monero GUI Wallet, which I mined in chunks of about 0.7925 XMR each. When I send 250 XMR (in 1 transaction), my wallet splits it into 3 transactions:
Unfortunately, Bridgoro only picks up one deposit:
I did not receive an "Offer Underpaid" email.
Considering Bridgoro didn't pick up on the full amount, I expected it to return the 115.093352523206 XMR (based on the following quote), but that didn't happen:
My offer for 115.09~ XMR is now available on Bridgoro. This looks like a bug: when it's fixed, I can test it again.

So, we are still investigating this issue, but as promised, we want to share some preliminary details about what we have uncovered so far and briefly explain how the system works and how we plan to address it.

The exchange mechanism is designed so that the buffer wallet counts only one incoming transaction and compares it against the on-chain balance. It's also hardcoded to calculate fees based on just two operations: the recipient's transaction and the network fee. As we've seen, Monero has the peculiarity of splitting a single transfer into multiple outputs. The same situation will occur during the reverse payout: the recipient's fee will also be split into several outputs, but our system calculates the fee for only one outgoing transaction, not for multiple outputs.

Right now, rewriting the internal exchange logic would take several months, including extensive local testing. We initially considered adding support for crediting multiple outputs, but that approach introduces the risk of recognizing fake tokens embedded within the native coin. To avoid this, the system intentionally counts only the first transaction that will be confirmed on-chain. There are many possible solutions, and the debate can go on forever, especially around creating Monero-specific workarounds. But Bridgoro will manage real user funds, and we don't want to rely on duct tape. The system must be designed cleanly around predictable, controlled functionality.

Why did your 250 XMR offer still process but end up counting only 115 XMR instead of a rollback?
The problem is that the system confirmed the balance on the blockchain, which reflected the full 250 XMR, but it only counted the first input of 115 XMR. Because of that, there was no rollback of the 115 XMR and the remaining inputs went into the Dumb Fee category. This is a temporary solution, and any exceeded amount can be retrieved through the Collector Module after a short investigation.

The solution we've decided on for now:
We will update the logic so that the system validates the exact transaction amount, rather than relying on the total wallet balance. With this update, the transaction will be canceled when there's a mismatch, and the user will receive only the amount from the first output. Any additional inputs (second, third, etc.) will remain in the buffer as Dumb Fee, and can later be recovered through the Collector Module.
To prevent this situation in the meantime, the system will temporarily limit XMR amounts to avoid triggering multiple inputs/outputs. As a result, during the launch phase, users won't be able to exchange more than $5,000 worth of XMR at once.

If someone intentionally attempts to exploit this behavior and sends a larger transaction anyway (as you demonstrated), any resulting loss of XMR will be the user's own responsibility, since they actively bypassed the system's constraints.

Overall, everything here is still preliminary. We are continuing to research and evaluate different solutions to ensure the behavior is handled reliably and securely.

I haven't tested it, so if this has already been discussed, just ignore my comment.
For a refund, it must be possible to add another address, not the same one from which the coins were sent. Users will often send a deposit to Bridgoro directly from another exchange, where it is most often an operational hot wallet, and the refund to such an address will not end up with a specific user.

We will review this and likely implement it as well.
However, since many parts of the exchange feature were hardcoded, this update will need to be addressed after the release. Rewriting and testing it locally will require additional development time.

Let's test:
When selling Monero, it asks for a "Monero Rollback Address". But when selling Bitcoin, it doesn't ask for a return address.
I've created a new Order, and sent (test) Bitcoin from these addresses:

Code:

4783615x18x0   	tb1q6hlep3yytgv6q0dl8uuj932y9hvhwnqqzvhza5	     0.00031652
4783799x37x0   	tb1qxjlzu5vsgudzhrl7fzfngm604cntwjt848lwkr	     0.00100239
4783604x18x1   	tb1qy2pjce6er89ruymwcp25xyggw8pz623z54xgvh	     0.00149947
4783801x31x0   	tb1qt0e3gd4zzm5zxtu0taathmnr0efpjhy8m2kn3j	     0.00022149
4783604x4x0    	tb1qqd2zx6lcfd98pnpzn5drls780s2s46x6sxek7s	     0.00014469

I'll see what happens when I Cancel my transaction when it's confirmed (which will probably take 2 hours).

Please share your results here once you are done testing.
I want to emphasize that your tests are currently among the most important ones for us.

[NotATether]

Hey NotATether, glad to see you in our open beta.
Thanks for sharing this issue. We have already been working on it since we received a report about the JWT topic on Telegram.
We need some time to evaluate and decide on alternative token approaches for securely storing user-related information.

You don't need to make an alternate approach, you just need to remove all of the logging to console.

As I said, it should not be this easy to obtain the credentials. They should only be stored in local storage because there could be a camera, a screen recorder etc capturing the devtools screen.

JWT with refresh keys is actually one of the safest authentication methods, especially if the access tokens expire after a short time.

[Bridgoro]

You don't need to make an alternate approach, you just need to remove all of the logging to console.
As I said, it should not be this easy to obtain the credentials. They should only be stored in local storage because there could be a camera, a screen recorder etc capturing the devtools screen.
JWT with refresh keys is actually one of the safest authentication methods, especially if the access tokens expire after a short time.

Now I see your point.
Before we move forward, let me clarify a few things so you fully understand our side as well:

We've already moved Bridgoro into production mode and except testnet environments, test logs, and similar components. Right now, we are monitoring this part closely to identify what needs further improvement.

The logs you currently see are still there because we are keeping them for development purposes.
The console logs will be removed next week.

[LoyceV]

To prevent this situation in the meantime, the system will temporarily limit XMR amounts to avoid triggering multiple inputs/outputs. As a result, during the launch phase, users won't be able to exchange more than $5,000 worth of XMR at once.

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.

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.

Let's test:
When selling Monero, it asks for a "Monero Rollback Address". But when selling Bitcoin, it doesn't ask for a return address.
I've created a new Order, and sent (test) Bitcoin from these addresses:

Code:

4783615x18x0   	tb1q6hlep3yytgv6q0dl8uuj932y9hvhwnqqzvhza5	     0.00031652
4783799x37x0   	tb1qxjlzu5vsgudzhrl7fzfngm604cntwjt848lwkr	     0.00100239
4783604x18x1   	tb1qy2pjce6er89ruymwcp25xyggw8pz623z54xgvh	     0.00149947
4783801x31x0   	tb1qt0e3gd4zzm5zxtu0taathmnr0efpjhy8m2kn3j	     0.00022149
4783604x4x0    	tb1qqd2zx6lcfd98pnpzn5drls780s2s46x6sxek7s	     0.00014469

I'll see what happens when I Cancel my transaction when it's confirmed (which will probably take 2 hours).

Please share your results here once you are done testing.

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.

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.

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