Proof-of-Concept

Moeda.Casa
Search…
Moeda.Casa
Introduction
Problems & Motivations
Proof-of-Concept
What is Next?
↣ MØΞDΛ
Kripto Solutions Team
Proof-of-Concept
Based on personal experiences and collective hypothesis, we gathered a team of skilled people to transform the Problems & Motivations into a Software Solution.
(diagram of main system actions and relations)
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)
1
# Contract's lifecycle: 
2
[:waiting_payment, :pix_received, :processing, :error, :refunded, :expired, :sent]
Copied!
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)
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!
Problems & Motivations
What is Next?
Last modified 3mo ago
Copy link