Description

The problem

Business transactions are more complex than they appear: they can involve multiple parties that don’t trust each other, they can be comprised of multiple payments over time, and are often regulated by contracts. Because of all these reasons, businesses have to hire the service of expensive third-parties to act as the trusted party in a transaction. Things become even more complex when you have to trade with a business based in a different country.

Cryptocurrencies solve the issue of cross border payments, but that’s only a small part of the problem. Take for example shipping an item internationally: buyers don’t want to pay in advance because they don’t know if the item will be shipped, sellers don’t want to ship before receiving payment.

Our Solution

LockerX uses Stellar Smart Contracts to solve the aforementioned problem of trust between different parties. Stellar Smart Contracts are purpose-built accounts that are limited in the operations they can make, this makes them easier to audit than smart contracts on other platforms.
LockerX creates and manages smart contracts for you, you just need to choose your use case and fill in the required details. In the future, we want to bridge the gap between the digital cryptocurrency world and the real world by making the smart contract legally binding. Imagine digitally signing a sale contract and at the same submitting a payment, all in one transaction!

LockerX Dashboard

The first smart contract we present is for Proof of Funds: the funds are locked in the smart contract until the other party confirmation, after that the funds will be returned to the owner wallet. For operations that modify the state of the smart contract, we always include a link to Stellar Expert so you can audit every operation.

LockerX Verify

More about LockerX

LockerX includes a custodial wallet that is used to keep users funds and create smart contracts. The wallet secret key is stored on Google Cloud SQL (encrypted at rest) and encrypted using Google KMS. Only one non-exposed service has access to this data. As support for SEP-0007 wallets increases, there will be less need to use this intermediate wallet.

We are good citizens in the Stellar Ecosystem: all wallets and smart contract accounts receive their unique federation address so they are easier to share with others. All smart contract transactions have a link to Stellar Expert so they can be independently audited.

LockerX accounts can be protected with Two Factor Authentication, visit your account page to enable it.

Goals

Integrate with wallets and the Stellar ecosystem

We do not want to create yet another walled garden application, for this reason, we believe it’s fundamental to integrate with the wider Stellar ecosystem:

  • Implement SEP-0007 (Delegate Signing) to let users create a smart contract using their favourite wallet. More security-conscious users will appreciate that funds will always be under their control.
  • Implement SEP-0006 (Anchor/Client Interoperability) to let users deposit and withdraw fiat and cryptocurrencies.
  • Expose and document the HTTP API we use to create smart contracts. This API will let users automate their workflow.

Develop more Smart Contracts

Now that we have completed building the backend infrastructure and found a satisfying way for users to interact with smart contracts, we can continue to build more (and more exciting) smart contracts that mimic existing commercial contracts:

  • Letter of Credit/Escrow: the funds are locked and kept safe until the business transaction is completed.
  • Vesting Payments: used to pay, for example, a contractor only after some milestones are met.
  • Security Deposit: this is similar to the UK Deposit Protection Scheme. The funds are locked for a predetermined period and released only after the two parties agree how much of the deposit will be returned.

Integrate with existing electronic signatures legal framework

The long term goal is to provide a tool that replaces existing financial contracts, to achieve this we need to integrate with the existing legal framework that is concerned with electronic signatures. We will start by looking at the EU eIDAS regulation and how it can be applied to our use case.

Timeline

Short Term (Q1 2020)

  • Implement SEP-0007
  • Document and expose HTTP API
  • Add more smart contract types

Long Term:

  • Implement SEP-0006. This goal can be moved to earlier if it gains wide support before Q2 2020.
  • Identify a Law Firm that can partner with us to work on the legal side of LockerX smart contracts
  • Grow the product development team

Links

Website: https://lockerx.co.uk
Twitter: https://twitter.com/lockerx_uk
Emails: info@lockerx.co.uk / security@lockerx.co.uk / privacy@lockerx.co.uk

Anything Else

There is not much information available on Stellar Smart Contracts, so we decided to start blogging about them:

LockerX is developed on .NET Core, as part of this project Francesco (@fracek) contributed with bug fixes and improvements to dotnet_stellar_sdk.

Hi,

Unfortunately, in most cases web-based wallets won't be able to support SEP-0007 request as this relies on a non-standard feature (https://caniuse.com/#feat=registerprotocolhandler).

In particular, web-wallet can't receive SEP-0007 request at all on smart phones - generally the most secure device to save your keys.

For transactions requests with wide support, you can take a look at CosmicLinks (https://cosmic.plus/#view:js-cosmic-lib). You'll find a demo interface there: https://cosmic.plus/js-cosmic-lib/web/demo

    MisterTicot As we discussed on Keybase, the plan is to use SEP-0007 to delegate signing of the smart contracts to wallets. I think giving control to users about which wallet to use is important so thank you for you comment!

      [deleted]

      At that time, Cosmic.link & Stellar-Authenticator.org are the only services that support 100% of SEP-0007. Lobstr & Stellarterm support a small subset of it, this is not known yet if they will go further. On their roadmap, they checked SEP-0007 support which may mean they won't.

      As I said, each of those services being web-based, it works with only 35% of the browsers as it relies on a non-standard feature.

      AFAIK Keybase doesn't support it yet - it has been delayed for months.

        To be clear, I'm not trying to say that SEP-0007 should not be used at all: the Cosmic.link front-end is both a valid SEP-0007 & CosmicLink handler, and it connects transparently with SEP-0007 wallets.

        At that time, this front-end connects to most wallet accepting arbitrary transaction requests, hence offer wider support than SEP-0007 alone. The only missing wallet at that point is Trezor.

        Likewise, cosmic-lib let you generate requests that can be sent both to CosmicLink wallets, SEP-0007 wallets or to the Cosmic.link front-end.

        What I'm saying is that, if one wants to implement delegated signing, he'll get better result going with CosmicLink because it'll give access to more wallets without losing the opportunity to connect with SEP-0007 ones.

        [deleted]

        So, do you confirm that none of these wallets are going to be able to sign smart contracts anytime soon?

        (Keybase support seems to be limited to pay links)

          6 days later

          @MisterTicot @[deleted] Just found this thread, decided to correct a few points here.

          As I said, each of those services being web-based, it works with only 35% of the browsers as it relies on a non-standard feature.

          This is not correct.
          Just go ahead and install LOBSTR on iOS or Android - and try for yourself.
          SEP-7 links work there out of the box, and they work great!

          Next week, we will also release the updated version of StellarTerm for desktop (Mac, Win, OS X) and that will bring SEP-7 there as well.

          Happy to discuss this further in Keybase if you have any questions 🙂

          Cheers!

            gleb

            The keyword here is web-based. Yes, applications installed through vendor stores can handle SEP7 links on Android & iOs. Webapps can't. That's my point & I think my assertion is accurate.

            For the background, I'm not a bored troll spitting random data for the fun of it. I've brought delegated signing into Stellar 20 months ago & since then most of my work revolved around it. I've explored many possibilities to find the best solutions and extensively commented on the subject. I've spent hundreds of hours working around this feature, as this is the central element of my software.

            I'm happy that devs finally get into it because that's the very point of my efforts. However, that's a bit annoying to see people waking up months after the battle & start contradicting - twice on the same point - without even checking the facts.

            The issues I've bought about SEP7 are well-known and were found by myself in the days SEP7 was still a draft. Those are the very reasons I continued to develop CosmicLink instead of withdrawing, as I know that this is an overall better-designed solution that is likely to become the community pick.

            The source I used to claim that only 35% of the browsers can register web-based handlers for SEP7 is caniuse.com. Their data is the foundation over which software such as Babel or Browserlist is built and are perfectly reliable. Virtually every software - including yours - rely on it as this is the reference of what browsers support and what they don't.

            Finally, I regularly check my software under various OS & browser - so I know the data is correct. Which means I also know that you did not properly test your product on the mentioned platforms.

            CQFD

              @MisterTicot Respect the work that you've done so far for sure.
              But I believe, that it is not the best place to hold this discussion, and won't contribute to it further.

              This post is about LockerX. @lockerx, I do apologize for the off-topic.

                gleb

                My point was to ensure the op get correct information about SEP7 and delegated signing, that he intends to use. I don't see how it is off topic. 🤔

                  Do you have plans to offer arbitration services? I guess that disputes resolution is the most challenging part of it. Even in the simplest escrow cases, there is always a chance that one party neglects the deal, lose private keys, or even die.
                  If you are ready to offer legal disputes resolution, then I'll definitely use your service. I understand that it's quite complex and you can't offer such services for free, but I'm sure that it's an emerging market with vast perspectives, and at the end of the day, users will be willing to pay fees for such a service.

                  Yes we plan to support this type of service. We already have been in touch with a London based law firm, we are applying to SCF so we can start working on this. We think this is very important and managing credit risk is a top issue, especially for people living in countries where the financial and legal frameworks are not as reliable.

                  Our plan from the beginning always included bridging the gap between cryptocurrencies and the real world since we recognize there are situations where smart contracts can fail and we need something more to solve the dispute.

                  For proof-of-funds, how it your solution different from simply proving you own an address (and it's assets) by signing a message off-chain? I mean, it's cute and all, with the locking, but there's nothing stopping me from disposing of the assets after I'm done proving I own them.

                  Thanks for the question.

                  The proof of funds is a first contract we built as an MVP. It's a way to get user feedback on how's the best way to interact with the chain. For example, signing transactions offline is not easy because not all wallets implement SEP-0007 so that they can sign any arbitrary XDR.

                  Now that we have enough feedback, we are working on other type of smart contracts where funds actually exchange hands between people.

                  Coolio! Looking forward to see what else is cooking.

                  Message signing isn't related to either SEP-7 or XDR. You'd just sign some random message, send signature + message to the recipient, recipient verifies the signature, validating that you know the private key used to sign. Nothing hits the chain.

                  There's is a lack of support for doing things like that though, in general. Bitcoin is quite good at it, Ethereum does it occasionally.

                  Yes sorry for not being clear enough. What I meant it's that there's not an easy (for the user) way to ask them to sign a transaction/data and get the signed payload to us.