search

ulex-opensource / Lexinomicon

Nomicon game space for Ulex
https://ulex-opensource.github.io/Lexinomicon/
4 stars 2 forks source link

Ulex-based Crypto trading software #25

Open proftomwbell opened 5 years ago

proftomwbell commented 5 years ago

Ulex-based software could improve crypto-currency. At present, large cryptocurrency trades are typically not automated. Instead, they involve multiple meatspace brokers on all sides using a variety of media, such as texts, Whatsapp, etc. They do not use escrow, there being no commonly accepted mechanism. They do not seem to do satisfy many formalities, either, leaving the parties unprotected by contracts, warranties, choice of law, choice of forum, etc. Such parties regard each other with mutual suspicion, so neither will accept the other's software or escrow service. There evidently is not already an open-source solution. That creates the opening for a Ulex-based one.

The bounty would call for the production of open source software capable of helping crypto-traders with the transactions now done so inefficiently. The software would allow traders to populate select fields to create a binding contract. It would impose a relatively (compared to the use of extant brokers) small charge, which would go to the Ulex Foundation or some other entity charged with keeping the software up to date, etc.

To promote adoption of Ulex, the contract would include language like this: "Ulex 1.1 governs exclusively any claim or question arising under or related to this Agreement. The parties represent and warrant they have substantial connections to Ulex, that they have reasonable bases for choosing that law, and that no state has a materially greater interest in the application of its law to the Agreement." That would settle the choice of law.

What about choice of forum? That's trickier. Here's some language: "Any claim or question arising under or related to this Agreement shall be resolved in the forum if any hereby designated by the parties to the agreement: [fill if applicable]; else in the forum if any designated by the protocol in which this contract is written (the EOS Community Arbitration Forum at https://www.eoscorearbitration.io/ would thus for example have jurisdiction over disputes arising out of transactions on the EOSIS blockchain); else the forum which heard a Ulex-based dispute closest in time to initiation of the accrual of the claim or question; but the first party if any to appeal to any other forum than these shall thereby forfeit all rights and remedies under this Agreement."

It would be better if there were a less awkward means of establishing the choice of forum. The way to fix that? Create an online Ulex court. But that is another project--perhaps one that the revenue from this project could fund.

For a template contract including those and other clauses, see: here.

macterra commented 5 years ago

This is a great use case for Ulex and it seems like the Lexinomicon bounty system itself would provide a good test case for the software since bounties are essentially held in escrow by the Treasurer until the Director approves the release of funds to the Executive, right? Maybe we could enhance the Btcpay server to include the fields specified in the template contract above? (As one possible implementation which would of course be up to whoever chooses to go after this bounty.)

proftomwbell commented 5 years ago

Agreed that the Lexinomicon bounty system might provide a platform for testing the escrow functions. In actual practice, the escrow might end up holding considerable funds. It is not clear whether Lexinomicon would offer a suitable escrow service if huge sums were at stake. But alternatives can get plugged in, later.

joestartupsocieties commented 4 years ago

I agree. Ulex would be great for OTC trades. Like you mentioned, many in the space view each other with mutual suspicion. This makes sense considering the sheer volume of BTC they are trading! Automation would reduce this, especially if using DLT that does it in the most transparent way possible.

However, one of the biggest obstacles is that every trader has specific requirements before executing a trade. Many trades stymie because one seller does not agree to the buyers’ KYC, or the seller doesn’t agree to the buyer means of money wiring. One possible solution is creating software that allows buyers and sellers many fields detailing their specific requirements (timeline, type of money wire, KYC/AML) and have buyers and sellers matched based on those requirements. This could be done in a basic form.

Another primary problem is that each of these deals has a representative that wants a cut. They represent a buyer or a seller and get a commission for facilitating the deal. The issue arises because no party wants to provide too much information about the buyer and seller they represent because they believe they will be circumvented. For instance, if a seller provide “proof of coin”, showing the public key address, the buyer can go to bitcoin.com’s wallet tracker and directly contact the seller themselves at a lower rate. If this software could somehow address this issue and automate it, the OTC market will grow tremendously. This is important considering that institutional investors are crowding in because of the bull market.

One the escrow side, I know of an organization that might fund something specifically about escrow. But we would have to provide something more detailed, starting here.

I guess a crucial question to get a bounty like this setup is to detail what other goals this software must achieve and any technical specifications. I’ll share this post to the Ulex network. But us ourselves should try to come up with something specific so we can make it a real bounty.

Flaxscrip commented 4 years ago

From the conversation so far, I see 3 categories of requirements for a Ulex-based crypto trading system. In all 3 cases, the Lexinomicon can be of help as we engage with the community to define crypto-trading best practices and software requirements.

  1. Rules and Best Practices - With Ulex at its core, we need to define a clear set of rules describing how traders want to trade. The efforts here are mainly procedural. These procedures will need to be maintained and continue to evolve with the marketplace and trading environment.

  2. Escrow - Our system should avoid holding or controlling funds. That is becoming pretty standard in the industry. We can integrate with any/many of the excellent existing wallets. Requirements here will mainly be integration with existing software.

  3. Automation - This is where we define requirements for what part of the process we want to automate. This will define engineering efforts for coding and/or platform selection

@joestartupsocieties - We can take a first stab at defining more details for each category and present the results here.

Flaxscrip commented 4 years ago

What do you guys think of OpenBazaar?

They have a completely decentralized marketplace, escrow, and P2P conflict resolution system. Very impressive platform. I setup a cryptotech.guru store to test it out and was clearly told that since I haven't selected an arbitration service, I was not likely to be considered for business on the network.

The Main OpenBazaar network OB1 contains many beautiful and sophisticated storefronts.

proftomwbell commented 4 years ago

Christian: OpenBazaar seems very legit (in the "decentralized transparently open sourced almost unstoppable" kind of way). Good choice.

Regarding "1. Rules and Best Practices": That requires defining the variables over which transactions range. The current draft Ulex Cryptocurrency Contract now has 15, some of which can have multiple values under subheadings. Joe said above that brokers care about KYC/AML standards and types of money wire, too, but it would be helpful to know more about how brokers handle those before adding variables for them. Defining the variables will prove essential for the Automation step.

Glad to hear that escrow can be handed off to third parties, Christian. Query whether users will find third parties wallets they can trust. Perhaps the contract could offer a wallet by default, making skeptics opt out for some other arrangement if they want to complete the deal. (Notably, default setting strongly influence outcomes. The draft contract thus sets the default for a very small donation to the Ulex Foundation.)

Joe notes that brokers currently worry about getting cut out of transactions, circling warily, withholding information, and generally raising transaction costs. "If this software could somehow address this issue and automate it, the OTC market will grow tremendously." Very useful info, that. The latest draft leverages it to make express provision for brokers' fees.

With the current setup, brokers will have a reason to direct customers to the crypto-contract, as they can type into it any side-agreement made by the broker to get payment for services. The use of the escrow service should help hide addresses, too, preventing runarounds. The new contract has provisions for paying escrow services via the same Contract, as well as donations for infrastructure support.

Flaxscrip commented 4 years ago

Very interesting new decentralized escrow protocol and API: https://github.com/escrowblock/exchange

Live/Production/Commercial system available here: https://escb.exchange/

Flaxscrip commented 4 years ago

Topic: Ulex Application Scope Workshop

Objective:

The goal of the workshop is to define a high-level scope for the development of a software application that utilizes, automates, or promotes the use of Ulex as an open-source legal code between trading parties. As a starting proposal, we used Tom's description of a Ulex-Based Crypto Trading Software posted in the Lexinomicon: https://github.com/ulex-opensource/Lexinomicon/issues/25

Main market problems identified as:

Executive Summary:

We did not reach consensus on scope for a Ulex Application. The 1.5 hours discussion was productive, generated numerous insights, and produced even more questions (see details below). Next steps: research and document opportunities for partnership with 3rd party projects and organizations that need (often without being aware of the need) better legal foundations for their communities, trades, or smart contracts.

Open | Close source:

An important discussion was triggered by Phil suggesting there may be more/greater opportunities in private (non open-source) applications of the technology. The point was recognized although Joe directed the group to focus on open applications since Ulex itself is designed as an open solution.

Excellent idea from Justin: "Regarding the startup vs open source tradeoff, I was wondering if we'd thought of the Seasteading approach. There's Seasteading organization that cultivates the concept and then there's a private commercial spinoff, Blue Frontiers. This model might work well for the API service mentioned above."

Competitors or Friends:

The Universal Legal Protocol for Blockchains (https://www.openlaw.io/) was brought up (by Phil?) as an example of an existing open legal solution. Tom lead an explanation (which I won't attempt to recap here, but you can buy Tom's book here: https://www.amazon.com/Your-Next-Government-Stateless-Nations/dp/1316613925) that concluded in a realization that many of these online communities and solutions still require something like Ulex as a legal foundation.

Ulex could be promoted as a way to strengthen the legal value that these existing networks provide to their customers. Integration with these systems could be as simple as a textual reference (ex: introduction to the Lexinomicon, which cites Ulex 1.1), an API integration, a plug-in, or more.

Projects that could benefit from Ulex:

Other Opportunities:

Some warnings:

proftomwbell commented 4 years ago

Following up on @Flaxscrip message of July 27 regarding ECSB exchange: It is hard to tell if the service includes a choice of law and choice of forum clause in their contracts. If they don't, they should, using Ulex for the first and a Ulex-friendly forum (unless and until we create one) for the second.

It also remains unclear if Openlaw.io offers an off-the-shelf module for its contracts for choice of law and choice of forum.

Open Bazaar evidently does require vendors to specify choice of law and choice of forum, as per the report of @macterra (if memory serves).

The EOS Constitution and arbitration system remains a dog's breakfast, legally speaking. Notably, however, someone at Block.one recently told me that the Constitution has no real effect on EOS transactions, which occur through projects that build on top of the EOS chain while interposing on users choice of law and choice of forum choices. That suggests the way to get traction in the EOS community is via the applications running on the operating system EOSIS.