Is Robosats a Scam?

After completing several successful trades with different coordinators on Robosats, I think it's a promising platform with great potential. The concept is appealing, especially as a non-KYC exchange tool, and I genuinely hope it gains more users and achieves long-term success.

However, I've recently experienced situations where I felt I was unfairly penalized, resulting in the loss of my fidelity bond for posting an offer. So far, this has cost me around 30,000 sats.

Here are the offer settings I used:

    Public duration set to 23:59
    Escrow/Invoice time set to 8:00

These settings should ideally allow you to sleep without risking your bond. If someone accepts your order right after you've gone to bed, the 8-hour escrow time should give you enough buffer to wake up, pay the invoice, and complete the trade.

The issue is that if someone takes your offer close to the end of the public duration—say, with only 1 or 2 hours left—the 8-hour escrow timer does not extend the overall duration of the offer. If you’ve gone to bed with less than 8 hours left on the public timer, you might have less than 8 hours to pay the escrow invoice before the offer expires and your bond is forfeited. This essentially penalizes users for not being able to respond instantly.

This setup seems flawed, as it forces users to stay vigilant during sleeping hours, risking money if they can't respond quickly enough.

I’m unsure if this issue varies by coordinator. Most recently, I noticed this with the Temple of Sats coordinator, but I believe I’ve had similar issues with others.

If this is the intended behavior, it raises concerns about potential bad actors using automation to take orders right before expiration, betting that the trade creators won’t respond in time—causing their bonds to be lost.

Has anyone else experienced this on Robosats? Any advice on managing it?

 @KoalaSat 

 That's not an intended behaviours. We tested setting a 20 min order + 8 hours scrow and it waited for the 8 hours
 I'll check that on a test instance for a real 24h + 8 as your case. 

 Clickbait title 😀 but apart from that – great catch, thanks for the heads up! 

 We tested all possible combinations because, as I said yesterday, the behavior described on the post were not intended. 

I was not able to reproduce it even creating and waiting for a real 24h + 8h order. These are the steps I validated and confirm with multiple combinations:

- Robot1 creates an order with a 23:59h duration set and a 8h escrow/invoice wait time.
- Robot1 locks its bond and the order goes public
- After 21h public, Robot2 takes the order
- Robot2 locks its bond
- Robot2 completes all steps and just wait
- The initial 23:59h duration just passes and nothing happens because there is still 5h left from 8h escrow/invoice wait time
- Robot2 only lost its bond after the 8h escrow/invoice times up

That said, if anybody finds out this to be different please intermediately report it to your coordinator.

nostr:note1vwmaxu20cavvn4fe6yf9qgplfrd3jecph3g89vycj4gzk0ya9qlsycwet3