# Proof-of-Concept ![(diagram of main system actions and relations)](/files/-MdSJrRtOXz1kco4KXaF) First, we were very intrigued on how Binance - the most used Exchange in Brazil with 36% of all BTC trades (June/2021) - have no Bank account to operate in the country. It became an insight, when realizing they have a pool of local intermediates to process the millions of deposits they do have daily. On our Peer-to-Peer approach, **Buyers** come to *Moeda* willing to privately acquire cryptocurrencies/tokens as-soon-as-possible without any registration. Making complex simple: our platform allows a limited number of **Agents** to provide liquidity to a **ZEC Pool**, which is a Shielded Z-Addr observed and controlled by our own Zcashd node. Those agents are rewarded with a fixed (adjustable) 0.01 ZEC every time their liquidity are used. 100 transactions would award 1 ZEC. *Moeda* lists and maintains updated a previously-chosen list of +200 **Tokens** based on the **Swap** services we implemented for a few decentralized and centralized Exchanges. We call **Oracle** our methods to average their prices, taking in account some Risk factors such as average price change, learning the slippages, and also parse and present to the user some meta-information from distinct public APIs, such as average market capitalization and all-time-highs. Once the buyer requests a valid *Order = {Token, Amount, Wallet, Price}* by our front-end*,* we define it as a *Contract* to be executed, and our system generates a QR-Code for a BRL payment over PIX with a random UUID. Probably, the most important design choice for this solution is based on a new Brazilian Fintech digital Bank which has an unprecedented Open Banking API that enables *Moeda* to observe when a payment is done to our Agents, detecting a valid UUID:order paid on their BRL Bank history over an API. When the *Contract* has triggered a :*payment\_done event*, it evokes the Swaps, which mainly follows a 4-level dynamic route in between Zaddr>\[...]>$XYZ, finally sending the requested $XYZ amount to the buyers's wallet address. Furthermore, the encrypted *Contract* data on the database (read just by *Moeda* system) is automatically deleted once, * *on\_error* * *on\_refunded* * *on\_sent* * *on\_expired (when :waiting\_payment takes more than 10 minutes)* ``` # Contract's lifecycle: [:waiting_payment, :pix_received, :processing, :error, :refunded, :expired, :sent] ``` If malicious Agents fake a transaction in their bank account, it actually generates a bad order in *Moeda* and their deposited ZEC is "lost" to the Pool. Avoiding to proof a received payment would need to "break" the Open Bank access, also losing his funds. We considered a list of risky cases and implemented some solutions not \[yet] described here. Relevant information to consider: * The Buyer reads the name of the Agent during a deposit, and vice-versa. * It is provided by the Central Bank to any Brazilian eBank system. * It also shows the Agent's Bank being used; the Fintech mentioned before. * No other Agent's details is shown, when done by our QR-Code method. * The Central Bank "knows" a transfer happened from Buyer to Agent, when and the BRL amount * However, there is absolutely no other *track* in between the paid Agent and the Buyer. * Nor that this transfer was crypto-related. * **The paid Agent has NO information on both the wallet and the token amount sent to the Buyer.** * Our legal compliance collaborator informed that >R$35k deposits/month should declare Taxes. * The ability to choose to cross this margin should be implemented in the Agent's Panel. * *Moeda*, in this experimental phase, limits the maximum trade to R$2000 (\~$400). * The 0.01 ZEC fee taken by the Liquidity Agent represents 0.25% of the maximum allowed order. * (2000\*0.25/100) \~= 0.01 ZEC * It is taken even for the minimum amount processed Contract, variable for each token. One of the main challenges we had to keep the system working are the cases in which an order fails (PIX are experimental and some rare times it can take minutes to arrive, so the ordered price + slippage becomes invalid - the prices changed too much) so the buyer should be refunded. After realized this case, we had to rethink lots of strategies since it requires us to have an *:execution\_access* to the Agent bank. We postponed a solution since all Agents are known for now, they can read the source-code and trusted it to be done, but we would like to test some other better hypothesis we sketched, allowing Agents to scale out in a more private way. **Summary** * The Agents trust the system with their specific Open Bank access. * They act as a liquidity provider getting a fixed reward from transactions. * Buyers just chooses their token, amount and destination wallet. * A QR-Code is generated to be payed in a few minutes. * *Voilá!* The system makes it's magic and send the token to the user. * (or a refund happens) ![(sequence illustration overview)](/files/-MdT07izDd0uD3IqUvMp) We are proud to have a working prototype enabling users to receive their requested amount of Tokens privately sent by *Moeda* directly from FIAT payments without any registration. And more can be done! --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://kripto-solutions.gitbook.io/moeda-casa/proof-of-concept.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.