Detail Whitepaper GitHub Comment Analysis

WebSite	https://omisego.network/
GitHub	omisego/ewallet
Update Date	2018 Sep 03 07:09:03

Circulating Supply	140,245,392
Total Supply	140,245,392
Max Supply	0
Price	$3.2458692
Volume 24h	$43,491,360
Market Cap	$455,218,208
Change 24h	-9.06%
Update Date	September 26th 2018, 1:59:10 am

v1

There is a fundamental coordination problem amongst payment processors, gateways, and ﬁnancial institutions. For instance, a customer of a bank wishes to pay a merchant on another network. Traditionally, there have been signiﬁcant eﬀorts in engineering around payment systems which are compatible across payment networks and ﬁnancial institutions. These are usually constructed by creating a clearinghouse which manages the interchange, usually via a messaging network with either a central counterparty clearinghouse or nostro/vostro accounts. Examples include FedWire, CHIPS, SWIFT, consumer card payment networks, NSCC/DTCC, OCC, and ACH. These networks service diﬀerent roles and functions, including local/national payments, international payments, credit, equities/asset exchange, and derivatives. These centralized networks allow for the controlling entity to arbitrarily change the mechanisms, which result in signiﬁcant amount of transaction costs via information costs, due diligence, and contractual enforcement between all parties. We believe that there is currently a large emerging market of disruption in digital payments with new payment platforms (e.g. Venmo, Alipay, etc.). These networks have signiﬁcant aversion to interchange across networks, as it usually requires signiﬁcant overhead costs in trust with the interchange facility. Parties are unwilling to use central counterparties, as neither party wishes to defer to the other, and use of nostro/vostro accounts require bespoke contracts between participants. While the larger networks have signiﬁcant incentive around protection of their network eﬀects, we believe that there is a long-tail of entities wishing to provide eWallet services which require greater coordination amongst multilateral participants. These mid-size participants will be able to cross value across networks in order to reach suﬃcient network eﬀects in usability. The infrastructure and reference frontend for these providers will allow for the network eﬀects to be encoded into this network, allowing for emerging eWallet participants to instantly create high network utility.

As this will be designed as a high-performant system, an linked-via-proof blockchain construction is necessary. We expect that this system will be able to handle extremely high volumes of transactions and hence, will only do ﬁnal delivery over Ethereum. Clearing and settlement occurs over the OmiseGO blockchain. Consensus rules are enforced via this proof-of-stake network. As part of the consensus rules of this network, it is required that all OMG (Omise GO) validators also run the Ethereum network to validate in parallel, resulting in Ethereum as a ﬁrst-class citizen with regards to inter-blockchain validation.

A VWAP of recent trade executions is computed and published periodically on the OMG blockchain as a consensus rule. This allows external contracts to use merkle-tree SPV proofs of trade execution prices and volume, hopefully creating greater viability in smart contracts.

A primary function of any exchange is not only managing the orderbook and executions, but having a feed for use with 3rd party systems. It allows for 3rd party systems to be able to use this information and for participants to net out activity on a single venue. As the basis for a exchange-rate/pricing mechanism is necessary for all manner of (smart) contracts, access to this system allows for participants in these external contracts using the exchange as a data feed to have greater assurance and transparency in execution. This allows for participants in contracts to create contracts with knowledge of the behavior and access to the decentralized exchange. If participants use the price oracle feed on the OmiseGO chain as the basis for pricing on smart contracts, they can have greater assurance of execution by placing orders on the OMG chain, this creates signiﬁcant network eﬀects of the OMG chain with greater adoption of smart contracts.

The central component for an eWallet interchange platform is a decentralized exchange. While this supports issued tokens from EPPs, it also supports trading between decentralized cryptocurrencies. A decentralized exchange may be ideal for eWallet interchange, as they may have diﬀerent underlying representations of value, and even when transacting with the same underlying, there’s diﬀerent counterparty risk and costs. eWallet A is diﬀerent from eWallet B’s, even if they are backed by the same thing. For that reason, a liquid market is necessary for proper market operation (even if the exchange rate diﬀerences are miniscule).

The decentralized exchange will initially use a batch-auction construction where every round exchange matching occurs. It is possible to buy into particular rounds (block-heights), or to leave open orders on rounds until the order is ﬁlled. A batch auction allows for orders to be placed and execution happens at once at a speciﬁc interval. This construction allows for higher assurance and performance over a decentralized network. Orders may be left on the orderbook, but execution can happen quick enough to be comparable to EMV card terminals (requires more research with the consensus mechanism). In the event there is insuﬃcient speed for particular use cases, EPPs are responsible for holding balances of other EPPs they wish to support for fast transactions (they may charge a higehr spread), this can be used for things like small everyday purchases and larger value purchases are via the Decentralized Exchange.

While it is desirable to be able to perform low-latency high-frequency order execution, there are signiﬁcant impediments to doing so in a decentralized network. It is a necessary function of order matching that execution is occurs at a single point. Without execution where an order occurs with a single ”engine”, it opens the possibility to either sybil attacks or trust in a single party. If one can make an order and have execution occur at many places, then no real order commitment has occurred – one can easily sybil the network and pretend to self-execute. Additionally, with untrusted execution venues, it’s not possible to create a ticker for use externally with smart contracts – a necessary function of this network. The purpose of this network is designed with the goal of being the preeminent high-value exchange and settlement platform (not a high-volume low-value network). An alternative which allows for fast execution with low-latency would be allowing for external centralized venues, however, this establishes trust in execution on a single entity. As trading liquidity naturally centralizes (far stronger than payment centralization), there are signiﬁcant trust/coordination problems, which end up looking like current cryptocurrency exchanges (with the only diﬀerence being that it is non-custodial). This construction, however, does not resolve signiﬁcant coordination problems around participants needing to resolve a coordination issue around not wanting to trade on a single trusted vendor. The goal of OmiseGO’s decentralized exchange is to have transparent, known execution behavior. We believe that trusted non-custodial execution is a credible option as a complement to a decentralized execution engine and OmiseGO may support these platforms in the future as well. A mature decentralized exchange has the beneﬁt over a non-custodial trusted execution environment of being able to use it as a decentralized oracle for smart contracts. This decentralized exchange is designed to be high-performant where orders are propagated over the proof-of-stake network. When suﬃcient participants have the order with block conﬁrmations, the order is then placed on the order book. The order book for a particular batch-execution point is a running tally of all orders which do not execute until the batch-execution point (so there are orders which are matched on the book). The initial conﬁguration includes transparent orders, but it is possible to do a fauxcoin-like construction whereby blinded orders are placed, then no more orders are accepted, the blinding keys are released by the participants who placed orders, and ﬁnally execution occurs after a set time. Initial versions will use a fully transparent system (which a batch-execution format mitigates some amount of adversarial behavior).

Transaction fees are native to the OmiseGO chain. The validators earn fees from validating the activity of this blockchain. Payments and interchange fees are used to pay for activity on this network and to incentivize honest activity. Bonding has a cost, those who bond on behalf of others on this network will likely charge fees, e.g. clearinghouses.