NVO Cross-platform Modular Decentralized Exchange

  • The Safenetwork is decentralized and doesn't rely on the traditional
    routes or ICANN. By employing a validator on the Safenetwork for orders
    validation, a P2P trustless decentralized exchange can be created.



    Assets are locked in wallets' local storage away from any server.


    No personal data or private info. Communication are secured by the Safenetwork.


    Direct exchange between wallets without the use of proxy tokens.

    Full Autonomy

    Assets are always under users' full control even during exchange.

    Multi-Assets Storage

    Users can enable as many different assets as they want through an open plugins system.

    Integrated Platform

    Being dynamic means we can bridge utilities from other projects like XRP fiat gateway.

    Details about Modular projects



    Initially the wallet will be provided with limited features then these enhancements will be implemented
    ● Multisignature addresses
    ● Addresses management
    ● Account management
    ● Offline storage
    ● Offline management
    ● Assets creation and management
    ● Support for Ethereum tokens
    ● Light Nodes
    ● Staking wallets
    ● Multiple languages

    These features will be implemented at different stages of development. 

    The wallet will use random password and pass phrases dynamically generated using the CPU entropy or another provider of random data.

    Each wallet will generate a Unique User ID. It will be used by the validator for order origin and transactions history. This ID will be used to manage the user accounts in the wallet and enable the support for multiple accounts in the same wallet. This ID will never be used to track users. Personal data will never be asked, collected or sent to any third party.

    As an account management system will be implemented in the wallet, it is normal that multisignature addresses will be enabled as well as part of the advance features created for experienced users. Users can generate as many addresses as they need. The address management let users select which address will be used to receive or send transactions comparable to Coin Control. It will display the available receiving addresses and sending addresses.

    All these features will be available online and offline. Users will have the ability to “prepare transactions”. Prepared transactions can be either broadcasted when the wallet goes online, or be deleted.

    The wallet will support popular cryptocurrencies on default. Some of these cryptocurrencies have tokens creation functionalities. This can be supported due to dynamic nature of the wallet through a flavour plugin system. It’s also possible to get the transactions history for these tokenized assets. The main technical difficulty here is the support of Ethereum tokens and smart contracts as they require the usage of a node to retrieve the required informations.

    Efforts have been provided by the original creators and maintainers of cryptocurrencies to provide 

    nodes” possibilities to developers. These light nodes will be progressively added to the wallet. The main
    problem is the possibility to run them all at once. Supposing that a wallet supporting 10 different
    cryptocurrencies. Each one with a Light Node implemented means that the wallet will have to manage 10
    different networks at once. This will lead to an increased bandwidth usage and CPU usage.

    As the wallet should notify the users about incoming transactions, either on mobile or desktop, the networking problem is an issue for development. Depending on the feedbacks received from the users, NVO may either enable networking via Light Nodes for features like transactions broadcasting or to trigger notifications for incoming transactions. Or disable it and rely on the API clusters via

    subscription method which means that each address owned by the user will have to be passed to the API cluster to keep track of the balance.

    An updater will be provided with the wallet. It will be used as a base module for the development of the
    plugins system allowing cryptocurrencies developers to create integrations in the wallet and allow users to
    choose which cryptocurrency they want to hold in their wallet. The plugins will be developed by either by any
    third party or by the NVO team. These will provide the users with features they would like to add to the
    wallet, reduce the size of the initial downloaded package and extend the possibilities of the future
    integrations and innovations from other projects.

    The wallet could be used to stake POS coins, as part of the objective to provide an alternative to the usual
    wallets and strategy to grow the userbase. This feature will be enabled in the later development stages as is
    requires a lot of setup, a mature code, and an extended test flow.

    API Clusters

    The Demo release uses different APIs to gather the required informations for the wallet either transaction
    history, broadcasting, balance checking and even cryptocurrencies prices.

    To provide a continuous service without having to supply any information to third parties, an API cluster
    network will be deployed. It is a simple architecture meant to provide different informations to the wallet
    and ease the integration of tokenized assets and functions from the different cryptocurrencies that may not be available using the common API.

    The advantages are : 

    ● Lower running fees than subscribing for a paid API provider. 

    ● Better response time 

    ● No country limitation 

    ● Customized data formating 

    ● Usage of advanced functions 

    ● Support for all cryptocurrencies 

    ● Doesn’t require to send high level informations 

    ● Availability guaranteed with API failover

    Inconvenience :
    ● Data stream interception (MITM)
    ● DDOS vulnerability
    ● Brute forcing

    Regarding the inconveniences,, many solutions can be applied. NVO could use some of the available crypto
    projects to encrypt the data streams (Namecoin, Nexus) and communications even if the informations
    exchanged won’t be of critical level, users may want to keep their transaction history or orders history
    private. NVO will never send the private keys, seeds or the password to unlock the wallet, these will left at
    user's’ local storage.

    These clusters don’t require a lot of maintenance and are easily deployable. The most important part is to
    create the required calls and functions in the processor to return the required datas to the wallets and the

    NVO will consider different strategies regarding the calls, and the technologies to use. For example, a
    websocket can notify users when a payment arrives to the wallet, but it is not handy when it comes to
    broadcasting a transaction, as it is usually made to receive live data feeds while a REST API is great at
    processing data on demand, but it is poor with live feeds as it relies on AJAX calls. Webhooks may be
    interesting but they are known to be a source of security issue if not implemented wisely.

    This architecture enables the usage of failover. If any API cluster is down for any reason, is unreachable, or
    with a high response time, the wallets will move to another cluster. We could limit the amount of users
    connected to a single cluster to reduce the payload and direct the wallets to another cluster to provide a
    short as possible response time.
    If at any moment, the communication between the API clusters and the users needs to be encrypted to
    provide a better security level, the usage of encrypted data streams will be enabled using SafeNet or
    TrustNet or Namecoin encryption methods.

    Ultimately the API clusters may be removed or kept in a minimal state depending on the evolution of NVO
    wallet and exchange. The ultimate goal of each module is be entirely automated and to rely on it’s own
    resources to get the required informations.


    The validator is a SafeNet application that will parse the orders sent from the wallets. Each order will contain
    informations about the user’s request. It will verify these informations, queue the order and check for a
    matching order.
    Each request sent from the wallet will contain these informations. These can change during development :
    ● Order information
    ● Trading Pair
    ● Order Type
    ● Amount
    ● Price
    ● Address A
    ● Address

    Validation Process :
    The first verification made by the validator upon the reception of a request is to validate the balance of
    Address A. If the amount has changed during the issuing process, the request is rejected and a message is
    returned. If the balance is valid the request turns into an order then it is queued for matching.
    Once an order can be matched with another, the validator sends a payment request with order information,
    sending addresses, receive addresses, and the amount of each currency to both request issuers. On the
    wallet side, when the message is received, the balances are checked. If the amounts are sufficient to cover
    the fees of the transaction and the trade, a raw transaction is created and signed then returns to the
    validator in Hex format.
    Once the raw transaction is received, the validator will parse it and verify the addresses and the balances
    validity. If everything is valid, the transactions are broadcasted. Transaction hashes, order summary and
    useful informations are sent back to users.

    The downside of this system is that each wallet must be online to conclude the trade resulting in users no
    longer to be able to shut down their devices after placing an order. Offline trading won’t be supported. A
    solution may come up, but it would be hard to apply it without compromising the decentralization of the
    trade at this particular time of the Safenetwork’s development. To compliment this downside, UX developers
    will make sure orders are seen and executed faster than ordinary exchanges by several methods. One
    example is by putting the latest trade order in a section of the wallet seen by all wallet users, as well as a
    maker-taker fees system encouraging users to provide liquidity rather than fulfilling existing orders. This
    downside won’t affect the user experience as long as the exchange process is convenient and can be
    fulfilled quickly through a large userbase from the wallet. This also means that it's important to implement
    several strategies to acquire more users to use the wallet.

    For offline trading, a probable, yet conditional solution may be applied. It consists on a 1of2 multisignature
    address shared between the user and the validator to enable offline trading in a decentralized environment.
    The user will provide a currency pair to trade, and an amount, the order will be listed for matching, and
    when the validator finds a matching pair it will sign the transaction using its key. It can be considered as a
    shared account between the validator and the user. This solution poses some questions regarding
    decentralization. The functions will be secured and automated by safenetwork and a smart contract, but it
    isn’t decentralized as the validator is now holding assets.
    Another probably theory for offline trading that was given from an outside source is to implement both the
    wallet and validator on the Safenetwork. This means keys will be securely stored on the Safenetwork
    accessible at any time. If the Safenetwork is unhackable this is an approach that could be taken and can
    provide other benefits as well such as hosted recovery features. This won’t be reasonable to implement
    during testnet or Alpha stages.

    Exchange limitations

    Supposing the wallet supports 10 cryptocurrencies, and the NVO Exchange enables the trading of each
    currency with another. Users will have 100 pairs to trade and most of them would be just irrelevant due to
    liquidity being so spread out.The temptation to enable the possibility of exchanging to each currencies with
    another is great, however, the users will be lost in the exchange process.
    This is why two different markets will be enabled, a main market and a sub-market.
    The main market: Enabled the trading of the major cryptocurrencies, like Bitcoin, Ethereum, Litecoin,
    Monero, Dash …
    The Sub Market: some cryptocurrencies has the ability to create tokenized assets. These will be traded on
    the sub Market. The pairs matching will be Cryptocurrency/Tokenized asset ie: ETH/GNO, BTC/MAID ,
    It means that for each supported currency that can create tokenized assets, a sub-market will be enabled to
    allow the trading of these assets as long as they are supported by the wallet. Assets created from the
    submarket can also be exchanged with Bitcoin.
    This option of dual market brings ease of use for users and is easier to scale as running on Safenetwork
    won’t be free, thus the available resources are used for the most popular pairs. Creating low volume pairs
    will result in more storage space and a waste of costly resources.
    The exchanging operations will be held on the SafeNetwork. Each step will happen in a different
    decentralized settings without the intervention of a 3rd Party. This means that the exchange won’t suffer
    from any country limitation as the mechanism will be hosted on a distributed network using the capacities of
    different decentralized providers.

    Plugins system

    This system will be built on top of the updater and will use the same routes and servers. On the wallet side,
    the users will have access to a tab displaying the plugins.
    The wallet may have to be reloaded depending on the nature of the plug-in. Some can be loaded directly
    after downloaded while others will trigger a wallet reload.
    The most important part of implementing a plug-in system is to enable a reverting possibility. This will be a
    mandatory prerequisite to any plug-in.
    Plug-in types:
    ● Cryptocurrency support.
    ● Prototype feature.
    ● Flavour plugin.
    These plugin categories are the main ones that will be added. Other types may be added later depending on
    the needs for them.

    Cryptocurrency support plug-ins enable integration of new cryptocurrencies into the wallet.
    Prototype features will be released by the NVO Team. During the development, the NVO Team will release
    alpha features. Users that wants to participate in these test can download them separately. This will provide
    the NVO Team with better feedbacks regarding the stability and bugs of each feature.
    Flavours are wallets with different features than the basic wallet, as an example, a trading flavoured wallet
    will provide a trading focused user interface with enhanced features like enabled arbitrage with different
    The plugins system open room for third party services and companies to build services within the wallet. An
    ecosystem can be created that will help acquire users for the wallet and ultimately to the exchange. A
    payment system can incentivize developers to add productive features to the wallet or help companies
    create paid products as a plugin.

    NVO Token

    NVO token will be used to pay out 50% of all fees collected on the exchange on a monthly basis. NVO tokens
    holders will receive NVOS. Both of these assets can be tradeable on the exchange with NVOS being at a fixed
    price of $0.999. A smart contract can be used to automate the distribution process in a transparent way
    without the need of human intervention.
    The fees will be paid on a monthly basis as soon as the exchange enters into production mode. A smart
    contract could be set here to manage the payment of the different API Clusters and to provide the required
    SafeCoins to keep the system automated, bringing autonomy to the exchange.
    More information regarding the crowdsale will be disclosed later.

    Demo Wallet:





    Yanni Bragui - Lead Developer and CTO

    14 years of experience in software engineering. Software developer for
    ERMA , the biggest research center in africa for light and street light.
    Head of development of Veserus, a fully licensed cryptocurrencies

    Ton Bi - CEO and cofounder

    5 years of experience in growth hacking for startups. Previously project
    manager for Newnote Financial Corp., a Bitcoin public company in
    Vancouver, Canada.








    Email:[email protected]

  • How to invest in NVO?

    Optional steps:

    This is only required if you don't already have a Bitcoin address to which you own the keys to.
    Step 1: Download and install a Bitcoin wallet (Supported Ways of Generating an AddressElectrum Installation Guide). Run it and back up your wallet!
    Step 2: Generate a new address in your wallet and send the amount that you want to invest to it.

    Mandatory steps:
    Step 1: Register an account on the NVO website: https://nvo.io/register.php. If you've sucessfully registered, you will see this screen:

    Step 2: Confirm the account by clicking the link that you've received in your email account.

    Step 4: Enter a personal Bitcoin address, one to which you own the private keys to (do not use exchanges, web services, and similar). This will enable you to see the Bitcoin escrow address and will generate an unique address for each coin.

    Step 5: Depending on what you want to invest with, there are two possibilities here.
    Step 5.1: If you are investing Bitcoin, then send from the personal address that you've previously entered.
    Step 5.2:
    If you are investing any altcoin, then send to the addresses that you
    see in your dashboard. The tokens will be credited to the entered
    Bitcoin personal address.
    Supported ways of generating a personal Bitcoin address:

    Where to get help? (ordered by speed)

    Note 1: All images are clickable and will lead you to the origin/they can be viewed in full size.
    Note 2:
    This is open to suggestions and will change/update depending on those.
    The list of supported ways of generating a Bitcoin address will
    definitely update frequently.

Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.