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

[LoyceV]

Testing the exchange feature grants more points to the participant.

I can't think of any other way to test an exchange

Public request for some testnet coins:
tb1qgvnfr7zvz0wj5a3ucfxcx6tvtx38yv5mma3j57 (Bitcoin testnet 3)
72bgNP7NQQ9i6yLpxXAbwHL2mMXaErgq796eXAZdVuLUUwoyRSM2yJ7fGxpFVXqxaR4yhcPjEeQMEgc X8UUW2N4wHaRW2du (Monero Stagenet)
Thanks, I have enough for testing If you need Monero Stagenet: ask me!)

[masulum]

#1 Pages unable to load

I try to fill the offer from this feature on home page


after clicked go to exchange I'm redirected to this page


Pages url: https://bridgoro.com/user/explore?inputAsset=ETHEREUM_GWEI&outputAsset=BITCOIN_SATOSHI&amount=0.001

but, after clicking Explore Offers menu from the page, it wan't load the page,

even the url success being updated to https://bridgoro.com/user/explore?inputAsset=&outputAsset=&amount=0

the pages still not redirected or not loaded the default explore page



From other pages its working properly only after following that way the explore offers won't load.

#2 overpayments stuck on buffer address

overpayments are not sent back to the sender.
Offer ID: 8da3f6b9-6b10-4fa7-afa7-532e476538a7
order amounts: 0.00359622 ETH
payment amounts: 0.005

Buffer address: 0x446AAcD5b1CedfE466bC4CF065e2350CC4e11441

From docs mentioned

If the transferred funds exceed the required amount, the platform locks the necessary portion for the transaction and initiates a partial rollback for the excess funds. This prevents unnecessary funds from remaining in the buffer wallet and ensures the user's assets are handled efficiently.

To make sure this is not a bug, i tried to make another transaction with detail:
Offer ID: 8da3f6b9-6b10-4fa7-afa7-532e476538a7
Amount sent to buffer address: 0.01 ETH
ETH needed for transactions: 0.003595788 ETH
Buffer address: 0x8cda83eA8ee74e6c61eBA16F0adC7abAf051E366

The remaining tokens should be refunded right? it's need a minimum? if yes how much the minimum? since in sepolia, if not a bug, it should be enough to refund

#3 Completed tasks not counted

my completed tasks is not counted.


Tested using chrome v142.0.7444.176


Well, the transactions proccess is very smooth right now. congrats Team, you are doing great job. Trade, rollback and cancel working properly from my side. only some minor bugs above from me.

tb1qgvnfr7zvz0wj5a3ucfxcx6tvtx38yv5mma3j57 (Bitcoin testnet 3)

0.00015294 BTC sent to you.
.

[Bridgoro]

I can't think of any other way to test an exchange
Public request for some testnet coins:
tb1qgvnfr7zvz0wj5a3ucfxcx6tvtx38yv5mma3j57 (Bitcoin testnet 3)
72bgNP7NQQ9i6yLpxXAbwHL2mMXaErgq796eXAZdVuLUUwoyRSM2yJ7fGxpFVXqxaR4yhcPjEeQMEgc X8UUW2N4wHaRW2du (Monero Stagenet)

Hey [LoyceV], we've sent you some BTC and XMR.

tBTC Amount: 0.0003
TX: 5d204892896a8c97ac360755dd0df17c1d104849a10b6dfb16b05eb1ebe26817

XMR (Stagenet): 0.06

We would send more, but all our testnet BTC and XMR are currently locked in Exchange Offers. However, this amount should be enough for at least 2-3 exchange transactions.

#1 Pages unable to load
I try to fill the offer from this feature on home page
after clicked go to exchange I'm redirected to this page
Pages url: https://bridgoro.com/user/explore?inputAsset=ETHEREUM_GWEI&outputAsset=BITCOIN_SATOSHI&amount=0.001
but, after clicking Explore Offers menu from the page, it wan't load the page,
even the url success being updated to https://bridgoro.com/user/explore?inputAsset=&outputAsset=&amount=0
the pages still not redirected or not loaded the default explore page
From other pages its working properly only after following that way the explore offers won't load.

This isn't a bug but a content filter. Your URL contains filter parameters, which is why you are seeing no offers, because there are simply no offers that match those parameters.

However, while testing your report, we did find another bug and added it to the backlog. The newly discovered issue is related to mismatched trading pairs: for example, if you select XMR-SOL on the homepage and click Go To Exchange, the system starts filtering the trading pair in reverse.

Additionally, we can see that this homepage feature may not be ideal, because users might think there are no exchange offers available at first glance.
We are considering revising that block on the homepage and replacing it with a shortened list of available Exchange Offers, so visitors can immediately see the available offers without needing to register or log in.

#2 overpayments stuck on buffer address
overpayments are not sent back to the sender.
Offer ID: 8da3f6b9-6b10-4fa7-afa7-532e476538a7
order amounts: 0.00359622 ETH
payment amounts: 0.005
Buffer address: 0x446AAcD5b1CedfE466bC4CF065e2350CC4e11441
From docs mentioned

If the transferred funds exceed the required amount, the platform locks the necessary portion for the transaction and initiates a partial rollback for the excess funds. This prevents unnecessary funds from remaining in the buffer wallet and ensures the user's assets are handled efficiently.

To make sure this is not a bug, i tried to make another transaction with detail:
Offer ID: 8da3f6b9-6b10-4fa7-afa7-532e476538a7
Amount sent to buffer address: 0.01 ETH
ETH needed for transactions: 0.003595788 ETH
Buffer address: 0x8cda83eA8ee74e6c61eBA16F0adC7abAf051E366
The remaining tokens should be refunded right? it's need a minimum? if yes how much the minimum? since in sepolia, if not a bug, it should be enough to refund

So here's where the fun part begins:
Yes, you pointed it out correctly in the GitBook article regarding the Rollback Mechanism. That was our initial idea (when we were writing the Whitepaper) for cases where a user sends more than the required amount. However, during internal testing, we encountered several transactional issues, specifically stuck transactions because in such cases the Escrow Mechanism would need to perform three transactions at once (instead of two):
1/ Send funds to the recipient
2/ Send the service fee
3/ Send the exceeding amount back to the user

The Escrow mechanism calculates the network fee only for two transactions. So if the exceeding amount is smaller than the network fee, the entire exchange operation could fail and get stuck solely because of that extra amount.

To avoid this, 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.

P.S. The GitBook has been updated with information about the Dumb Fee.

#3 Completed tasks not counted
my completed tasks is not counted.
Tested using chrome v142.0.7444.176
Well, the transactions proccess is very smooth right now. congrats Team, you are doing great job. Trade, rollback and cancel working properly from my side. only some minor bugs above from me.

Only tasks that require proof are countable. Claim tasks are not included in this. To avoid any misinterpretation, we will work on adjusting this section to make it clear for everyone.
Also, soon we will extend Whipaper with Tasks details.

Btw, our avatar looks funny  

[masulum]

This isn't a bug but a content filter. Your URL contains filter parameters, which is why you are seeing no offers, because there are simply no offers that match those parameters.

If it's not bug it's okay, but maybe you can check this video, hopefully better to understand what i mean,
https://www.youtube.com/watch?v=nRIq8e4TznU

To avoid this, 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.

P.S. The GitBook has been updated with information about the Dumb Fee.

Thank you for updates, because I tried several times with higher amount there was no single excess amount sent back to my wallet. and, i don't know whether it works automatically or not.

this buffer wallet 0x8cda83ea8ee74e6c61eba16f0adc7abaf051e366 holding the rest 0.00640537 ETH, while the transaction only need -0.00359458 ETH, before it, I think the remaining ETH in the buffer should have been automatically sent to the sender wallet to rollback the excess money, because it was sufficient to be returned even if the sending fee or service fee was deducted from balance.

PS. just want to know the mechanism, whether this is a bug or not, but since this is a beta test a detailed explanation will be very meaningful for users.

Only tasks that require proof are countable. Claim tasks are not included in this. To avoid any misinterpretation, we will work on adjusting this section to make it clear for everyone.
Also, soon we will extend Whipaper with Tasks details.

Ah i see, so I need to sent manual proof to get it count.

Btw, our avatar looks funny  

#4 Error notif for claim daily task

I just trying to claim daily points, yesterday it worked without any error, but today i found this error notification

it say already exist, but i just clicked it once today, after refreshing the page, the task still available and claim button still active.

Complete trade with no error, no pending transaction happens



good job team 

[Bridgoro]

If it's not bug it's okay, but maybe you can check this video, hopefully better to understand what i mean,
https://www.youtube.com/watch?v=nRIq8e4TznU

I saw the video.
Just press Reset Filters button and everything will be displayed. In the video, you are pressing the Explore Offers button while a filter is still applied.

Thank you for updates, because I tried several times with higher amount there was no single excess amount sent back to my wallet. and, i don't know whether it works automatically or not.
this buffer wallet 0x8cda83ea8ee74e6c61eba16f0adc7abaf051e366 holding the rest 0.00640537 ETH, while the transaction only need -0.00359458 ETH, before it, I think the remaining ETH in the buffer should have been automatically sent to the sender wallet to rollback the excess money, because it was sufficient to be returned even if the sending fee or service fee was deducted from balance.
PS. just want to know the mechanism, whether this is a bug or not, but since this is a beta test a detailed explanation will be very meaningful for users.

We will work on improving this mechanism, but for now we are keeping the Dumb Fee solution. If the exceeded amount is significantly large, the Collector Module can retrieve it after 7 days.
However, users should also be careful when sending transactions, always double-check amounts and addresses. That's why we added a COPY button under each data field.

Reworking the Escrow Mechanism right now would break many parts that are functioning correctly, just to prevent a rare user mistake. That's why we keep the current approach and call it a Dumb Fee.

Ah i see, so I need to sent manual proof to get it count.

Yes, please check this on your side and let us know how it works.

#4 Error notif for claim daily task
I just trying to claim daily points, yesterday it worked without any error, but today i found this error notification
it say already exist, but i just clicked it once today, after refreshing the page, the task still available and claim button still active.

That's definitely a bug, and we will fix it within a few days.
Status: [Added to backlog]

Complete trade with no error, no pending transaction happens
good job team 

All of this is thanks to you guys.

[AakZaki]

If I may offer a suggestion, when a transaction is processing, could you remove that element in the lower-left corner? It keeps appearing and disappearing, and it really distracts from the scenery. My eyes keep getting pulled to it, and it ends up straining them.

If it absolutely has to stay, maybe place it in the center of the details section instead just don’t make it pop in and out repeatedly.


After the transaction is complete, I want to close the transaction view, and then it appears like this second image in the Bottom right corner of "Invalid Auth Token" appears suddenly and repeatedly.


Then I refresh the browser appears like this third image, after I click "Show Error" occurs as in the fourth image and finally occurs Logout by itself

[Bridgoro]

If I may offer a suggestion, when a transaction is processing, could you remove that element in the lower-left corner? It keeps appearing and disappearing, and it really distracts from the scenery. My eyes keep getting pulled to it, and it ends up straining them.
If it absolutely has to stay, maybe place it in the center of the details section instead just don’t make it pop in and out repeatedly.

Thank you for joining the OPEN BETA.
And thank you for the suggestion we will consider how to improve it or hide it in the next update.

After the transaction is complete, I want to close the transaction view, and then it appears like this second image in the Bottom right corner of "Invalid Auth Token" appears suddenly and repeatedly.
Then I refresh the browser appears like this third image, after I click "Show Error" occurs as in the fourth image and finally occurs Logout by itself

We already mentioned the Session Expiration bug in a recent post, and we will fix it on Monday.

Known bugs:
- Session Expiration Bug
If you see an [Invalid Auth Token] popup, please refresh the page and then you should be logged out automatically. If not, log out manually and log back in.
- Unexpected Error Popup
If this message appears, simply ignore it. It occurs when your internet connection becomes unstable, even for a brief moment. But if you encounter it constantly and your connection is stable, then please report the bug with a brief description.
- Content Security Policy (CSP)
We experienced unstable behavior and several issues while using CSP, so it is not enabled in this patch. We will take additional time to test and update the relevant code to ensure stable performance in future releases.

[LoyceV]

Note: I've only used Tor browser.

While registering, I can't use my middle mouse to open the Terms & Conditions and Privacy Policy, so I can't read it on the size I want (but I've probably reported this already in the first Beta test). Also, the Terms are located under the reCAPTCHA, which I solved first (and that's no fun on Tor). Before I was done reading, reCAPTCHA expired and I had to do it again. Suggestion: put the captcha under the Terms and Privacy Policy links.

At the bottom of the site, I also can't use my middle mouse button on the Terms. I don't like being restricted in my normal browsing habits.
The only comment I have about the Terms: I find point 7 (Intellectual Property) a bit strange: I'm no expert on this, but are you sure you can "not claim ownership of IP" now, but still claim it later if you want? Isn't this a weird header to declare that it's closed source?

During the previous Beta test, my Tor browser stayed logged in for weeks. Now I have to lookup my password and go through captcha again quite quickly, even with "Remember me" ticked. I like the old default better, it was much easier to use.

I accepted 2 existing offers, and created 2 by myself.
I'm surprised how long it takes to buy XMR from BTC: for the first 6 confirmations I was looking at "PARTIALLY CONFIRMED". Does this have to be so slow? The trade confirmed after 7 confirmations (2 hours on testnet).
I don't think such small amounts justify waiting for that many confirmations. At least add the required number of confirmations for me to see while waiting, say: "5/7", or better: "5/2".
After this, I've sold XMR for BTC. That went a lot faster.

When creating an offer, I can select the "Price Margin". I picked 1.0%, and I know I can look it up, but this doesn't feel intuitive: does this mean I pay 1% more, or less? Maybe this can be added: "1% (you pay more)" to take away all doubt.

When I Create an Offer, I can choose the Minimum Buyer Level. Why would I, as a seller, want to exclude lower-level accounts? Is there a drawback in allowing them that justifies reducing my buyer base?

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.

Until now, I had been using Feather wallet for Monero Stagenet testing. But Monero GUI Wallet turns out to be more fun. It took a lot longer than expected to sync, but after that it's very easy to start mining. I quote: "It gives you a 1 in 1 daily chance of finding a block". So instead of scraping dust from faucets, all of a sudden I'm a Monero Stagenet whale If anyone wants a coin, let me know. Or just buy it with my brand new 1 XMR offer on Bridgoro at 5% discount

[masulum]

#5 Typo's on Docs
Typo's text that i found (marked with red)

Section: How to create an exchange offer



but you will lose in exchange the the percent from the exchange that you put in Price Margin.

Reason: Double the the

Section: 1.2.1. Backend > Technology Stack



Framework: Rust.

(CMIIW, Rust is a language not a framework, right?)


Section: Deal Status - The stage of a Deal:



Accepted - Deal accepted by Seller.
Accepted - Deal accepted by Seller.
Reason: Doubled

Section: Privacy Policy > Contact



contact form on the Bridgoro exchange or via Tekegram.

[Bridgoro]

Note: I've only used Tor browser.
While registering, I can't use my middle mouse to open the Terms & Conditions and Privacy Policy, so I can't read it on the size I want (but I've probably reported this already in the first Beta test).

Yes, we are aware of the middle-mouse open in new tab issue, and it will be fixed in our next patch update.
T&C and PP currently open in a popup screen where you can hide the right bar. And you are the second tester to suggest moving these two sections to a separate page. We will consider this.
By the way, the T&C and Privacy Policy can also be found in our GitBook and read there. (T&C - GitBook / PP - GitBook)

Also, the Terms are located under the reCAPTCHA, which I solved first (and that's no fun on Tor). Before I was done reading, reCAPTCHA expired and I had to do it again. Suggestion: put the captcha under the Terms and Privacy Policy links.
At the bottom of the site, I also can't use my middle mouse button on the Terms. I don't like being restricted in my normal browsing habits.

T&C and PP can also be opened on the homepage at the very bottom.

The only comment I have about the Terms: I find point 7 (Intellectual Property) a bit strange: I'm no expert on this, but are you sure you can "not claim ownership of IP" now, but still claim it later if you want? Isn't this a weird header to declare that it's closed source?

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.

During the previous Beta test, my Tor browser stayed logged in for weeks. Now I have to lookup my password and go through captcha again quite quickly, even with "Remember me" ticked. I like the old default better, it was much easier to use.

During the first Beta, JWT (JSON Web Token) had a 365-day session expiration period. This was done to make internal testing more convenient and avoid constant re-login.
Recently, we updated Bridgoro to production mode (except for the testnet environment), and now, for security reasons, a user session expires after 1 hour if Remember Me is off, and after 48 hours if Remember Me is enabled.
We understand that this may be inconvenient when using TOR, but many testers highlighted session expiration as a necessary security feature.

I accepted 2 existing offers, and created 2 by myself.
I'm surprised how long it takes to buy XMR from BTC: for the first 6 confirmations I was looking at "PARTIALLY CONFIRMED". Does this have to be so slow? The trade confirmed after 7 confirmations (2 hours on testnet).
I don't think such small amounts justify waiting for that many confirmations. At least add the required number of confirmations for me to see while waiting, say: "5/7", or better: "5/2".
After this, I've sold XMR for BTC. That went a lot faster.

BTC requires 6 confirmations to change the status from Partially Confirmed to Release Ready. We understand that BTC testing is slower than other assets, but 6 confirmations is the minimum required to keep exchanges secure.
We could reduce it to 1 or 2 confirmations, but that introduces risk, especially for larger amounts.
Anyway, the slow transaction speed is due to Bitcoin's architecture, and we can't change that. Lowering the number of required confirmations would be risky, but we've selected the best possible confirmation count to avoid security issues while still making the process faster than waiting for all confirmations.

When creating an offer, I can select the "Price Margin". I picked 1.0%, and I know I can look it up, but this doesn't feel intuitive: does this mean I pay 1% more, or less? Maybe this can be added: "1% (you pay more)" to take away all doubt.

We clearly explained the Price Margin section in our GitBook, but for better UX, we will consider how to make this part more intuitive and user-friendly.
Price Margin links: Glossary, My Offers page (paragraph 8 ).

When I Create an Offer, I can choose the Minimum Buyer Level. Why would I, as a seller, want to exclude lower-level accounts? Is there a drawback in allowing them that justifies reducing my buyer base?

This feature was added as a future improvement to the exchange, for cases where a seller doesn't want to trade with new accounts and prefers to work with proven users who have a higher XP level.
In a way, the account level system serves a similar purpose to Bitcointalk's account levels.

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.

We understand your point, but we cannot remove CAPTCHA or the session expiration timer.

Until now, I had been using Feather wallet for Monero Stagenet testing. But Monero GUI Wallet turns out to be more fun. It took a lot longer than expected to sync, but after that it's very easy to start mining. I quote: "It gives you a 1 in 1 daily chance of finding a block". So instead of scraping dust from faucets, all of a sudden I'm a Monero Stagenet whale If anyone wants a coin, let me know. Or just buy it with my brand new 1 XMR offer on Bridgoro at 5% discount

In this case, could you please send us some test Monero?
XMR address:

Code:

75saVbZzQ7nHAwZcX4ZfnPTqrgdjfLiTfBwsAEt4WB2BCxZA2y1qPcST2EW6mYJVUseYoSb3Hg1JDCUV7jyw3ZXoPLEUhg1

#5 Typo's on Docs
Typo's text that i found (marked with red)
Section: How to create an exchange offer
but you will lose in exchange the the percent from the exchange that you put in Price Margin.
Reason: Double the the

Yes, that was a typo. Thank you for catching it. It has now been fixed.

Section: 1.2.1. Backend > Technology Stack
Framework: Rust.
(CMIIW, Rust is a language not a framework, right?)

The framework is Axum based on Rust, we simply forgot to include it. It's added now.

Section: Deal Status - The stage of a Deal:
Accepted - Deal accepted by Seller.
Accepted - Deal accepted by Seller.
Reason: Doubled

Fixed.

Section: Privacy Policy > Contact
contact form on the Bridgoro exchange or via Tekegram.

The typo has been corrected, and we added the necessary hyperlinks as well.

[Bridgoro]

SESSION EXPIRATION test

Guys, we've fixed the Session Expiration bug.
Could you please test the session expiration timing on your side?

FYI:
Log out and log back in with Remember Me disabled. In this case, the system should automatically log you out after 1 hour.

If Remember Me is enabled, your session should remain active for 48 hours.
But for now, we want to test the short session first, so please log in without the Remember Me option.

[masulum]

#6 Bug Auto Confirmations Without Clicking Confirm Deposit Button Not Worked

I read on telegram,

The system begins scanning for confirmations after you press the Confirm Deposit button.
However, even if you don't press it, the system will still move the deal into scan mode after a short delay. This means you can try accepting an offer, sending the funds, closing the page without pressing Confirm Deposit, and then checking again later, you will see that your transaction was received and counted.

So, i try to not to click the confirm deposit button after sending SOL to buffer wallet. but, after one hour (Order created: 1/12/2025, 15.40.42 GMT+7 or 08:40 UTC), the order has been canceled by system instead of detecting the deposit as mentioned on telegram.



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


after checking my deal history, it confirmed as deposit timeout.

[btcnbegun]

8.

Range bug:

There is a scope to add username based login or forgot email option when available.

Recaptcha error
Opera version: 123.0.5669.47

Login interface isn't solving the challenges like before which makes it prone to bruteforce attack. There isn't any script blocker installed IYK.

Bruteforce using dirb,





PHP 402 Empty\

Port scanning:



Port ::2052 open service unknown: [responds to scanning]

quering cddbp CD DataBase Protocol (CDDBP) is cd-rom compact disc.

The service on :8880 is not using SSL encryption. Its unsecured.

Your IP address is 104.21.27.207 and cloudflare is the dns provider.
There is an incident when cloudflare changes name servers without prior information. So if there is a pro plan that’s better.

Name Server   COLIN.NS.CLOUDFLARE.COM
Name Server   DALARY.NS.CLOUDFLARE.COM

1034 filtered ports. That’s a lot of filtered ports.

[Woodie]

Telegram Update via Repost.

Bug Reports / Answers & Status Updates

************

1. Cookies
Report from @BrunoSolna
Message Link: https://t.me/bridgoro_beta/445

We didn't add Cookies intentionally, as it doesn't make much sense for a no-KYC/AML exchange. However, after the Beta test, we will add a popup screen that informs users that certain third-party services may track activity on the platform.

Status: [not a bug]


************

2. Several Aria Hidden Elements
Report from @Cyberczar
Message Link: https://t.me/bridgoro_beta/444

No, it won't subject Bridgoro to any lawsuits.

Many websites use aria-hidden, and its usage is determined by individual developers based on accessibility requirements, typically to hide decorative icons or other non-essential elements from screen readers.

An aria-hidden element is simply an HTML element with the attribute aria-hidden="true", which instructs assistive technologies like screen readers to ignore that element and its contents. This means it is hidden from users relying on assistive technology, while remaining fully visible to sighted users.
It is commonly used for hiding purely decorative content, offscreen information, or duplicated elements that would otherwise cause confusion in accessibility tools.

Status: [not a bug]

************

3. Loading Spinner Even After Page Load
Report from @Cyberczar
Message Link: https://t.me/bridgoro_beta/443

This was already reported in the Bitcointalk thread, and we will fix it in today's update or, at the latest, in tomorrow's.

Status: [already added to backlog]

************

4. Privacy and Anonymity Breach
Report from @Cyberczar
Message Link: https://t.me/bridgoro_beta/442

A few words about true anonymity:
When you turn on your PC, mobile device, or anything that connects to the internet, you are already exposed and no longer truly anonymous. I'm currently working on my own article about this topic (still a WIP), and I hope to share it shortly after the release of Bridgoro.
Long story short: any device, any transaction (even Monero) can be tracked.
If you are interested, check out the old documentary Citizenfour.

Status: [not a bug]

************

5. Session Timeout Implementation Leaks Sensitive Data During Re-authentication
Report from @Cyberczar
Message Link: https://t.me/bridgoro_beta/441

On one hand, you are right about the exposure of user data during a session timeout. However, on the other hand, if someone gains access to your screen whether during the timeout or before it that responsibility ultimately lies with the user.
Unfortunately, we can't cover every security aspect, as our budget is very limited, but we did implement one important measure in case of a security breach and someone gaining access to your account.
Please read this post.

Status: [not a bug]

************

6. Confirm Deposit
Report from @Thehunter707
Message Link: https://t.me/bridgoro_beta/440

Yes, that's correct if you don't press Confirm Deposit, the system won't scan the wallet. It was my mistake earlier (in this message) when I said the system would scan the transaction even if the Confirm Deposit button wasn't pressed.
It's hard to keep everything in the head, so I admit I gave you incorrect information, and I want to clarify it now: the user must press the Confirm Deposit button after sending the funds.
However, if the user sent the funds but didn't press Confirm Deposit, the funds can still be retrieved by the Collector Module.

Status: [not a bug]

************

7. ( i ) icon information display problems on mobile devices
Report from @Thehunter707
Message Link: https://t.me/bridgoro_beta/436

We confirm that this bug exists and have added it to our backlog. We will fix it in the next patch.

Status: [added to backlog]

************
8. Server-Side Implementation for X-Frame-Options
Report from @BrunoSolna / @Cyberczar
Message Links:
https://t.me/bridgoro_beta/213
https://t.me/bridgoro_beta/214
https://t.me/bridgoro_beta/215
https://t.me/bridgoro_beta/420
https://t.me/bridgoro_beta/421
https://t.me/bridgoro_beta/427

CSP, STP, X-Content, X-Frame, and HSTS will be implemented later, once we test them on our internal test server first. We can't apply these suggestions immediately, as doing so could cause system malfunctions.

Status: [added to backlog]

************

9. Contact Form Submit Button
Report from @kakibords
Message Link: https://t.me/bridgoro_beta/426

You forgot to choose a Subject. The SUBMIT button becomes active only after all mandatory fields are filled out and a subject is selected.

Status: [not a bug]

************

10. Email Change Toggle
Report from @Cyberczar
Message Link: https://t.me/bridgoro_beta/414

This was fixed. Please check.

Status: [fixed]

************

11. Email Change Toggle
Report from @AakZaki
Message Link: https://t.me/bridgoro_beta/411

We informed everyone about this session expiration bug in our latest post.
But it has been fixed for now.

Status: [fixed]

************

12. Deposit Status Text
Report from German Sniper
Message Link: https://t.me/bridgoro_beta/407

No, it's not misleading. As a user, once you confirm, the status you see is correct. But if another user accepts your offer, the status will remain "busy" the entire time until the deal is completed or aborted.
More details about Deal/Offer statuses can be found in our GitBook.

Status: [not a bug]

************

13. Exchange Feature UX
Report from German Sniper
Message Link: https://t.me/bridgoro_beta/406

Crypto is not beginner-friendly, and a crypto exchange is on an even higher level. Bridgoro isn't designed for beginners at all. However, to help users learn the exchange features smoothly, we created a step-by-step guide on GitBook.

Copying the wallet address and the amount is standard for 99% of exchanges, except for Web3 platforms, where you can connect your wallet. At this stage, we don't want to connect any user wallets and prefer to leave the transaction process fully in the user's control.

Status: [not a bug]

************

14. Overpayment
Report from @Cyberczar
Message Link: https://t.me/bridgoro_beta/404

Overpayments are fully under the users' responsibility. Unfortunately, we can't control users' actions. It's the same if you send it to the wrong address or the wrong amount.
At this stage, we can't easily add overpayment rollback
During internal testing, we encountered several transactional issues, specifically stuck transactions because in such cases the Escrow Mechanism would need to perform three transactions at once (instead of two):
1/ Send funds to the recipient
2/ Send the service fee
3/ Send the exceeding amount back to the user
The Escrow mechanism calculates the network fee only for two transactions. So if the exceeding amount is smaller than the network fee, the entire exchange operation could fail and get stuck solely because of that extra amount.

To avoid this, 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.

Status: [not a bug]

************

15. INITIATED or INITED
Report from @Cyberczar
Message Link: https://t.me/bridgoro_beta/403


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

Status: [not a bug]

************

[Bridgoro]

#3 Completed tasks not counted
my completed tasks is not counted.
Tested using chrome v142.0.7444.176

We added an (i) button with a popup message explaining that Claimable tasks are not applicable.

6 Bug Auto Confirmations Without Clicking Confirm Deposit Button Not Worked
I read on telegram,

The system begins scanning for confirmations after you press the Confirm Deposit button.
However, even if you don't press it, the system will still move the deal into scan mode after a short delay. This means you can try accepting an offer, sending the funds, closing the page without pressing Confirm Deposit, and then checking again later, you will see that your transaction was received and counted.

So, i try to not to click the confirm deposit button after sending SOL to buffer wallet. but, after one hour (Order created: 1/12/2025, 15.40.42 GMT+7 or 08:40 UTC), the order has been canceled by system instead of detecting the deposit as mentioned on telegram.
Transaction detail:
Offer ID: d1f0eccc-3ebc-4aba-a0c7-34bbc76b53aa
Solana buffer address: ARhSHx9W1qoRi2vKuaQZuY5NXck6E13Kywu7tUhhetbq
Hash of Deposited Solana: https://solscan.io/tx/52Hkd2nLqi5QjdAFnzfVEohHy2VXCrY86GcUiK7TgpzjKN177U5N49VEkjtykpeqzVzhQjVV1R7fPqnEoEN8YoNY?cluster=devnet
after checking my deal history, it confirmed as deposit timeout.

Confirm Deposit, the system won't scan the wallet. It was my mistake earlier (in this Telegram message) when I said the system would scan the transaction even if the Confirm Deposit button wasn't pressed.
It's hard to keep everything in the head, so I admit I gave you incorrect information, and I want to clarify it now: the user must press the Confirm Deposit button after sending the funds.
However, if the user sent the funds but didn't press Confirm Deposit, the funds can still be retrieved by the Collector Module.

Overpayments are fully under the users' responsibility. Unfortunately, we can't control users' actions. It's the same if you send it to the wrong address or the wrong amount.
At this stage, we can't easily add overpayment rollback
During internal testing, we encountered several transactional issues, specifically stuck transactions because in such cases the Escrow Mechanism would need to perform three transactions at once (instead of two):
1/ Send funds to the recipient
2/ Send the service fee
3/ Send the exceeding amount back to the user
The Escrow mechanism calculates the network fee only for two transactions. So if the exceeding amount is smaller than the network fee, the entire exchange operation could fail and get stuck solely because of that extra amount.

To avoid this, 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.

Range bug:

We see that this bug still exists from the first Beta, even though we thought it was fixed.
Let us double-check it, and we will fix it soon and report back here.

Recaptcha error
Opera version: 123.0.5669.47
Login interface isn't solving the challenges like before which makes it prone to bruteforce attack. There isn't any script blocker installed IYK.
Bruteforce using dirb,
PHP 402 Empty\

The CAPTCHA behavior is entirely handled by Google.
In your case, if the CAPTCHA doesn't present any challenges, it simply means Google considers you a trusted user.
Try turning on a VPN and checking again and I'm sure the CAPTCHA will behave differently in that scenario.
I can say with confidence that you cannot brute-force the CAPTCHA, even if you are marked as a trusted user. But if you somehow manage to do that, I would recommend contacting Google and collecting your reward from them.

Port scanning:
Port ::2052 open service unknown: [responds to scanning]
quering cddbp CD DataBase Protocol (CDDBP) is cd-rom compact disc.
The service on :8880 is not using SSL encryption. Its unsecured.
Your IP address is 104.21.27.207 and cloudflare is the dns provider.
There is an incident when cloudflare changes name servers without prior information. So if there is a pro plan that’s better.
Name Server   COLIN.NS.CLOUDFLARE.COM
Name Server   DALARY.NS.CLOUDFLARE.COM
1034 filtered ports. That’s a lot of filtered ports.

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

[masulum]

#7 Status Info Mismatch
I try to cancel my created offer, and in the cancelation detail it say "CANCEL_ROLLBACK_PARTIALLY_CONFIRMED"



while the transaction still unconfirmed yet



To make sure I'm not make a mistake, so i checked the docs and it say

Partial Confirmation - Initial confirmation level (e.g., 1 for BTC).

So, the info message for partial confirmation becomes the default message even if there's no transaction confirmation on the chain? If it becomes the default, I think the message is inconsistent with the documentation.

[LoyceV]

Recently, we updated Bridgoro to production mode (except for the testnet environment), and now, for security reasons, a user session expires after 1 hour if Remember Me is off, and after 48 hours if Remember Me is enabled.

Maybe you can look into why I get 1 hour even though I ticked "Remember me". Since it used to work when it was 365 days, it should be 48 hours now and not just 1. One hour isn't even enough for 6 confirmations, which means a user has to login again even before his transaction is completed.

BTC requires 6 confirmations to change the status from Partially Confirmed to Release Ready. We understand that BTC testing is slower than other assets, but 6 confirmations is the minimum required to keep exchanges secure.
We could reduce it to 1 or 2 confirmations, but that introduces risk, especially for larger amounts.

How about reducing it for low amounts? Anything under 1% of the block reward shouldn't really be at risk, and I think that's a conservatively low amount (but enough to make many transactions faster).

In this case, could you please send us some test Monero?
XMR address:

Code:

75saVbZzQ7nHAwZcX4ZfnPTqrgdjfLiTfBwsAEt4WB2BCxZA2y1qPcST2EW6mYJVUseYoSb3Hg1JDCUV7jyw3ZXoPLEUhg1

I'll send you 100 Stagenet XMR when I have 10 confirmations in Feather Done!

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

[Bridgoro]

#7 Status Info Mismatch
I try to cancel my created offer, and in the cancelation detail it say "CANCEL_ROLLBACK_PARTIALLY_CONFIRMED"
while the transaction still unconfirmed yet
To make sure I'm not make a mistake, so i checked the docs and it say

Partial Confirmation - Initial confirmation level (e.g., 1 for BTC).

So, the info message for partial confirmation becomes the default message even if there's no transaction confirmation on the chain? If it becomes the default, I think the message is inconsistent with the documentation.

We will double-check this part.
I believe now that the system switches to PARTIALLY_CONFIRMED as soon as it detects your transaction on the blockchain, and the Release Ready status appears after a certain number of confirmations.
But we will verify this issue regardless.

Maybe you can look into why I get 1 hour even though I ticked "Remember me". Since it used to work when it was 365 days, it should be 48 hours now and not just 1. One hour isn't even enough for 6 confirmations, which means a user has to login again even before his transaction is completed.

Yeah, some users are seeing the Session Expiration work properly, while others are not.
One of our own testing accounts isn't behaving correctly either, so we will continue working on fixing this issue.

How about reducing it for low amounts? Anything under 1% of the block reward shouldn't really be at risk, and I think that's a conservatively low amount (but enough to make many transactions faster).

The thing is, when we start creating and implementing different scenarios and rules for certain amount thresholds, more bugs begin to appear. Of course, we will continue working on constant upgrades and improvements for the project, but these changes will be implemented only after the release. Otherwise, adding such logic now would require launching another Beta test all over again.

I'll send you 100 Stagenet XMR when I have 10 confirmations in Feather Done!

Thanks a lot. We received 100 XMR.

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

We never encountered anything like this during our tests and planning, but now we need to verify it. Thanks for reporting it.
We will test an Exchange Offer by sending two separate transactions and will update you with the results.

[mocacinno]

Sorry i jumped the gun last time . Most of the "under the hood" stuff i wrote back then is still valid tough (checked again today). I don't know if you added my previous remarks to your to-do or to-test, but i tought it would be nice to present my findings again with some more context and tell you how you can check these things yourself if you want to fix them.

These might not be actual bugs, but it would still be nice if you fixed them none the less  . Just FYI, the rest of the post might sound harsh, but it's all pretty standard stuff you see quite often. Your site didn't have any major red flags  .
Personally i wouldn't use cloudflare, but i do get why some people do use them. Just know that cloudflare's biggest problem is the fact that they are a MITM. For the rest of my report, i basically only tested your cloudflare endpoint, because there's no way for me to reach your actual host. This being said: your host might be hidden for us, but somebody just scanning ranges might find it pretty easily. If you only depend on cloudflare as a WAF, TLS endpoint and DDOS protection, you might find yourself in troubles when somebody finds your actual host, and it's not properly secured.

Target: https://bridgoro.com
Date: 03 Dec 2025
Scope: Public-facing SPA behind Cloudflare CDN/WAF
Disclaimer: This is a non-invasive assessment based on publicly accessible data. No active exploitation was attempted.
Tools & Sources Used:

• testssl.sh (TLS)
• sslyze (TLS)
• curl -I (headers)
• wapiti 3.0.4 (vulnerability scan)
• Nmap 7.80 (vulnerability scan)
• wget (complete sourcecode)
• grep (to check sourcecode)
• https://www.ssllabs.com/ssltest/analyze.html?d=bridgoro.com&s=172.67.143.150

Summary
Your site uses cloudflare for TLS termination, but your setup lacks several security headers and allows legacy protocols (TLS 1.0/1.1) and CBC ciphers. This is also the reason why ssl labs grades your setup as "B" (which is still pretty good). I found some mixed content references in your sourcecode, risking downgrade to insecure connection. I haven't found any major injection vulnerability's, but because you haven't added CSP and other headers, your site might be vulnerable to clickjacking, MIME sniffing and XSS vectors.
I would defenately recommend to disable TLS 1.0/1.1, unless you really insist on serving those with devices that haven't been updated since 2015. I'd also recommend adding the necessary headers...

Findings
Finding: TLS 1.0 and 1.1 enabled; CBC ciphers allowed; only 2 SCTs for Certificate Transparency.
Reproduce: ./testssl.sh https://bridgoro.com/
output:

Code:

Protocols: TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3
Cipher suites: CBC present
SCTs: 2 (need ≥3)

Finding: No HSTS, CSP, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection.
Reproduce: curl -I https://bridgoro.com
output:

Code:

HTTP/2 200
server: cloudflare
cf-cache-status: DYNAMIC
(no security headers present)

Reproduce: wapiti -u https://bridgoro.com -o wapiti-report.html
output:

Code:

Strict-Transport-Security is not set
X-Frame-Options is not set
X-Content-Type-Options is not set
X-XSS-Protection is not set

Finding: CSP header absent; meta tag commented out in HTML.
Reproduce: wapiti -u https://bridgoro.com -o wapiti-report.html
output:

Code:

CSP is not set

Finding: Multiple http:// references in mirrored files; likely external assets or API endpoints.
Reproduce: grep -R "http://" .
output:

Code:

loads and loads of output, mostly from index.e13d35ca.js making runtime calls to non-HTTPS endpoints

Remediation

• HSTS header in cloudflare: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload"
• disable TLS 1.0/1.1 (only allow TLS 1.2+ and TLS 1.3)
• remove CBC ciphers
• add CSP via HTTP header
• add security headers X-Frame-Options,X-Content-Type-Options, Referrer-Policy,Permissions-Policy
• fix mixed content, replace all http with https in html, css, js and api calls

[Bridgoro]

Sorry i jumped the gun last time . Most of the "under the hood" stuff i wrote back then is still valid tough (checked again today). I don't know if you added my previous remarks to your to-do or to-test, but i tought it would be nice to present my findings again with some more context and tell you how you can check these things yourself if you want to fix them....

Thank you for testing the security components, but these security suggestions were already submitted earlier in Telegram, and we will definitely take them into account.
CSP, STP, X-Content, X-Frame, and HSTS will be implemented later, once we test them on our internal test server first. We can't apply these suggestions immediately, as doing so could cause system malfunctions.

So you can skip this part for now and continue testing the rest.