# What is Next?

## > jump into a possible future

As science fiction readers with tech skills, we can imagine a futuristic distributed system where everything are just coordinated ZEC transfers carrying *encrypted action* *messages and metadata on MEMO fields.*

For example, today, the weak side of privacy in *Moeda* are the known liquidity providers, who needs to send the private *bank\_history metadata,* so the system can detect a payment was done to execute the ordered Contract. This could be wisely solved with an *extended* logic on top of the Zcash node on the Provider's side, as a layer, privately reading his own bank account history, observing new payments and sending a *payment\_done event:message* to the pool's zaddr. We call it a *Smart Node.* In practical terms: if *Moeda* encodes the *Contract* UUID in the QRCode to the buyer, paid to the Agent, then, when the traditional payment is received with an identifier, this could be sent as a ZEC encrypted transaction to *Moeda Smart Node* as a proof it was received, and the Contract is executed with no need to *know* their bank history, in the Zero-knowledge spirit :D

![](https://3943311076-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MdRObbADxhOBEV7L-rG%2F-Mdr2t-YKFI7HF1aPjZU%2F-Mdr74GuEqO1CjVhop_L%2Ffuture.png?alt=media\&token=cdffb0b4-f67b-410c-8c31-e5c1890e6204)

*Moeda* started to conceptualize a [*Sentinel*](https://code.kripto.solutions/kripto/sentinel) *framework*, observing and acting upon the received MEMO messages of up to 512 bytes to a node. [*ZecPages*](https://zecpages.com/) is an interesting example on how people can LIKE or REPLY messages, as some basic *message-oriented (or* event-based) architecture using *Zcash as a distributed privacy layer.* They could also benefit from our framework, being able to abstract a *Smart Node* logic, focusing all development effort on the Board logic itself.

## < back to the next present

We had an exponential to-do list of tasks while developing *Moeda,* some we had to deprioritise - thankful for some project management collaboration, or we would still be playing around with the *Nodes* having triggered events from MEMO messages.

Practical next steps are,

* [ZeroMQ](https://zeromq.org/)
  * While, theoretically, our server+database can handle 300 requests per second, and *Oracle* & *Swaps* seems to run well coordinated on a few Threads, a basic *Chaos Engineering* evidences we need a proper asynchronous Message Queuing to handle it all before things scale out.&#x20;
    * We would like to prepare for concurrent Contract requests before an official launch.
* Websockets!
  * Prices should change on the front-end as they change on the back-end.
  * So do the Contract's status after a QR-Code is paid.
* Export RESTful services API as [ZKSwap](https://en.wiki.zks.org/interact-with-zkswap/restful-api) do, beyond [actual](https://moeda.casa/tokens.json)
  * Terminal CLI app
  * Implement a CryptoDealer Bot on Telegram
* DevOps
  * ~~precompile assets for deploy~~
  * ~~oracle workers as systemd.services~~
  * basic DDoS protection on NGINX
  * Docker image + scripts for a suddenly server change
  * keep server sockets alive for active connections during a new deploy
* Our Dev to-do list has many open tasks and ideas to refine the system as a hole.
  * UX
    * checkbox to "*hide wallet address*" on QR-code page
      * so "other payer" can become the buyer, unaware of Contract's wallet destination.
        * Contracts ($BRL->$XYZ orders) could be generated to third-party processes
    * Enhance CSS for mobile users
    * Adapt as a Progressive Web App
* Test! Test! Test! Test! Test! Test!&#x20;
* We also imagined an \~200-token to Shielded-ZEC Swap service, abstracting parts of our system.