$400
1stPrize
$200
2ndPrize
$200
2ndPrize
$200
2ndPrize
$200
2ndPrize
ARCHIVE

The competition and voting have completed. Winners were determined by the citizens of Lykke City.

  • Days of the project

    Jun 22 - Aug 30 (68 days)

  • Registration

    Jun 22 - Aug 22

  • Submissions

    Jul 15 - Aug 22

  • Voting

    Aug 22 - Aug 30

Every Lykke client has his / her own digital key that saves all the money kept in the Wallet. But the client may occasionally lose it, as well as backups of the digital key. This is the main problem that we want to solve.

Our method of private keys backup:

Digital key converted to 12 words.
Risk: Client may forget to save them.

The key is stored on Lykke server.
It is protected by the encryption client’s password so Lykke’s staff can’t steal it.
Risk: The client can forget his / her password.

The key is stored on client’s device.
Risk: The device can be stolen or broken.

 

About Social Recovery

Social Recovery allows you to recover your key, by relying on a network of trusted contacts for validation. These contacts can be friends or trusted institutions. This mode is usually reserved for potentially threatening circumstances.

Scenario

Phase 1 (User).
At this point, pieces of key are generated and sent to the trustees via the public channel.
Features:
- Ability to set parameters (number of parts and weight of each part)
- Ability to encrypt each and every piece using a public key (of a friend/relative) to be sent through a public channel
 
Phase 2 (Trustee).
At this point, the trustee retains a piece of the key in the local database.

Phase 3 (User).
If there is a need to restore the key, user sends the request to the trustees.
Features:
- Generate temporary public key (with temporary secret private key)
- Send this temporary public key along with a text message to the trustees asking to help with the recovery
- Ttemporary secret private key is needed to safely get pieces from friends to the client (the pieces should not be visible to Lykke, although the pieces go through the server)

Phase 4 (Trustee).
At this point, the trustee receives a request for recovery. The system decrypts a piece of a previously retained key and encrypts a piece with a temporary public key.
Features:
- Sending through a public channel

Phase 5 (User).
At this point, the key is decrypted:
- Collecting the encrypted pieces and decrypting them
- Calculating the private key by pieces

Performance requirements.

The Terms of Reference shall meet the following requirements:

  • Utmost clarity. Once the Terms of Reference are read, the developer should have no questions about the details of the software product that is being described. There should be no dual wording. The more specific the better. 
  • The Terms of Reference should have sufficient information to deliver it to the developer and start work.
  • The sections of Terms of Reference should not contain conflicting information.
  • The information must be well structured. Straight text is difficult to perceive and evaluate.
  • The document should not contain extraneous information that is not relevant to the development of the system and that does not describe an aspect of its operation: keynotes, questions, colored highlights, etc.
  • The future system should be fully described. In the case of phased development, the functionality of the relevant phase should be fully described.
  • If the to-be-developed system has similar programs and applications, it is better to provide links to them.
  • If the system involves integration with other systems, or if it uses other resources, you should specify them and provide all the necessary references and links.
  • When describing the purpose of the system, you should provide basic user scenarios.
  • The Terms of Reference should include examples of input data as well as data format to exchange between subsystems.
  • The Terms of Reference should include examples of output data as well.
  • Preferred development language is C#

The Terms of Reference structure

  • General information about the project.
  • The purpose and objectives of the development of the system.
  • General requirements to the system.
  • The composition and content of the work on system development.
  • Control and acceptance of the system.
  • Documenting requirements, including source code requirements;
  • You should draw the architecture (skeleton) of the system and also describe the relationships between the subsystems.

Future opportunities

The best participant can be hired by the Lykke Team.

About Lykke Wallet

Lykke is building a global marketplace where all asset classes and instruments can be traded. The exchange went live in June 2016 and is now in beta mode. Tradable assets include FX, bitcoin and Lykke coins (equity of Lykke). Lykke Exchange is using semi-centralized architecture. Matched orders are settled on the Bitcoin blockchain, where each successful trade between parties appears as a set of atomic colored coins swap transaction. The exchange does not take possession of the traded coins but needs to be trusted to match trades correctly. 
For more details see  Lykke Exchange white paper and  Terms of Use.

Support

Please refer to the Terms of Use for the organization and remuneration issues. If you have any questions, please feel free to ask them in the comments to the contest.

 

Username Registration date Result
July 30, 2017 03:53
July 20, 2017 05:12
July 21, 2017 02:00
July 16, 2017 02:34
Please login to leave a comment
Username reg. and Subm. Date Result Vote

For this project, none of the submitted results matched our experts expectations, so we decided not to award the first prize.

Your Feedback