:+1: :+1:

Hi, it's your legal dev here (such a thing exists since I just declared it so now). :slightly_smiling_face: . kidding. Anyway I am drafting some kind of simple waiver or Terms of Service for the exchange and I'd like help understanding two things:

1. I don't quite understand the, um, I guess I don't understand the basic operation. I've tried to describe it but please take pen and improve on it.

2. Could we open-source the code at time of launch? If so, that's great innoculation. It's not like anyone is going to read through the code from day 1, but it's a clean message if we're saying "here's a free project, it's open source, code is hear if you want to do your due diligence."

https://docs.google.com/document/d/1nr5t-6kYdIJD08EYRlXNjMH1bMs_H9H8eSvjbrxZl7c/edit?usp=sharing

@PAPACABEZA So how it works is that we hold two pools of funds. The rate is directly based on the proportion of the two pools. When a user enters their addresses, those are the addresses the user would receive coin back at. Then, the user sends to the exchange, and based on direct proportions, is immediately paid out to their addresses

For the "pools" there's one for BCH, and another for SNOW. Where are these funds sitting --- i.e., whose wallet the user's or the exchange's? Who will have "custody" of the funds while they are in the pool?

The funds in the pools belong to the exchange and are in wallets controlled by the exchange.

They exist to provide the exchange with the ability to immediately handle trades without waiting for a counter party

> The rate is directly based on the proportion of the two pools. I can't imagine this working out well at all

heh

It is actually pretty similar concept to a patent I have

Think of the pool amounts as a way that people will tune the system via trading

to find the price where most of the buys and sells match up

if it is ever off from that, someone will happily trade and think they are getting a good deal

and it will correct itself based on that trading

The patent is about balancing queue readers without communication but similar concept

but I've been wrong before

that is part of the fun

Basically, we want to describe the tech and the potential risks as much as we can so that users are knowingly taking on the risk. There's a challenge here, though, because FrostyTrader will be a custodian during the time that the crypto is in the "pools." Because of that, most regulators are going to want to call us a transmitter or some other kind of licensed exchange. I think we get out of scrutiny because it's small and experimental and it's a community project --- with no fees, brokerage, etc. The other part, though, is accurately describing the fucntionality and the risks (you could lose all your money if a hacker gets in, etc). Is this getting closer to accurate?

https://docs.google.com/document/d/1nr5t-6kYdIJD08EYRlXNjMH1bMs_H9H8eSvjbrxZl7c/edit

@PAPACABEZA So, there shouldn't be much time for that. We don't hold wallets for users or anything. It's literally a matter of, "the moment we see your transaction in, we send you the other coin"

The hard part is probably where the user must realize that if 100 trades are ahead of them, it can change the rate and they should hold off

(which is why the queue is displayed)

@Fireduck testing deployment webserver configuration, the page will be up/down on different ports, unless you need it to stay up

whatevers