FreeTON Self-Sovereign Identity Framework (Stage 2) & Roadmap

after stage 1 framework contest Contest Proposal: FreeTON Self-Sovereign Identity Framework (Stage 1) we drafted the roadmap to whole vision of SSI approach for FreeTON Stage 2: FreeTON SSI Roadmap (draft) - Google Docs

Please read and comment here in this thread or inside google doc (link above and comments are allowed)

let’s take a week for this discussion and prepare Stage2.Step1 contest after.



Roadmap (copied here from google doc)


The SSI concept appears to be one of the most prominent identity technologies. The main goal of SSI is to shift the locus of control over users’ data and authorization function. It gives back the power of profile control to people while preserving a prominent level of privacy and security. Trust triangle, which is the core of the SSI ecosystem, presumes that the User holds privately its own verifiable credentials issued by authorized actors (Issuers). This credentials are accepted and verified by Verifiers which check-up the Issuers signature and decentralized identifier of the User.

Various consortiums and state authorities have paid attention to the SSI development and have already undertaken certain actions to set up a proper agenda and to hold the best positions at the frontier of technology.

Being technology-agnostic the SSI, however, perfectly fits any blockchain ecosystem due to its decentralized and trustless character. Blockchain networks can perform the role of decentralized virtual machine for SSI-based smart contracts or even store the data of certain SSI components.

A Plan for FreeTON Community

Numerous blockchain ecosystems have already entered the SSI adoption race by promoting the development of basic SSI components. We strongly believe that the competitiveness of any blockchain ecosystem depends on the level of its mass adoption. SSI can become a game-changer. In connection with useful Telegram UX the SSI can become a Passport 2.0 with the ecosystem of credential providers and verifiers.

There is no doubt that open ecosystems stand on good standards that are open to the community. Hence, it is a necessity to develop a bunch of open-source projects that will correspond to the main components of SSI.

Therefore, we propose a X-step plan for the FreeTON community. While Step 1 is definite quite, Steps 2 and following might be expanded or slightly changed with moving on the roadmap.

Step 1. Decentralized Identifiers. Specification + DID Storage + DID method implementation + Use case (demo app)

This step sets up the work on the SSI ecosystem. Decentralized identifier is the basic component for each and every user flow. To start interacting with Issuers and Verifiers, the Holder must identify himself by creating an identificator that will reference it. This step must include

  1. A detailed specification for DID methods, DID Document and the description of DID resolver.
  2. A prototype of a smart contract that will perform the role of DID storage.
  3. Demo application showcasing DID creation, resolution, deactivation functionality
  4. IPFS module for DID Document storing.
  5. Gas consumption explanation.

This step must be finalized with a web2 prototype that simulates a real SSI use case but employs a DID module for authorization purposes. The use case must be practical and attempt to solve a real problem.


  • A prototype of the use case with implemented DID component
  • Documentation (how to reproduce locally)
  • Source code on GitHub

Terms: 1-2 months

Step 2. DID SDK + API

This step proceeds with the development of DID components. This step must include:

  1. An extended DID SDK. JavaScript library with CRUD functions to interact with Free TON ID on Free TON and IPFS
  2. DID controller for key rotation and its deactivation.


  • SDK + Documentation + Tests
  • Governance system & Upgradability

Terms: 1-1.5 months

Step 3. DID Resolver and FreeTON ID API

This step includes DID server-side implementation. Additionally, the Universal Resolver must be delivered. The step must include:

  1. DID universal Resolver. Resolver application packed into Docker container compatible to specification (Decentralized Identifier Resolution (DID Resolution) v0.2) and published to
  2. Free TON ID API, web service for dealing with DIDs.


  • Universal resolver + Documentation + Tests
  • DID management use case web service

Terms: 2-3 months

Further Steps for SSI Development

Step 4. Verifiable Credentials SDK + TON DID Method (with support)

This step implies the development of the extended SDK for TON DID and VC SDK. This components are necessary to involve Issuers and verifiers in the process of credential exchange and start to pilot first MVPs in the FreeTON ecosystem. The SDKs must include:

  1. VC issuance toolkit (timestamping; reference to Issuer’s DID).
  2. VC onchain revocation.
  3. VC verification
  4. Generation of Verifiable Presentation

Step 5. Verifiable Data registry. Revoke. Schema registry

This step proceeds the involvement of the ecosystem by creating certain registries that are necessary to build trust across the ecosystem.

  1. Verifiable Data Registry to store metadata and enable trust flow in SSI applications
  2. Onchain registries for W3C VC Issuers, Revoked Credentials and verifying VCs.

Step 6. Issuer Registry + Reputation System + Crypto economic model

This final step presumes a certain level of the technology maturity. At this stage we might see several MVPs employing SSI technology. However, to create a functional ecosystem it is necessary to implement various governance mechanisms that will create proper incentives for the participants. The step must include:

  1. The linkage process of Issuers’ DID and Holders’ VCs.
  2. A prototype of a reputation system for the SSI prototype based on VCs.
  3. A concept of crypto economic incentivization for the Trust Triangle participants

After our submission in Stage 1 of Free TON Self-Sovereign Identity Framework our team decided to proceed with the development of SSI ecosystem by presenting a DID component for Stage 2 Contest #39.

The description of the use case and its technical implications can be found at where our documentation repository is located. We kindly ask you to read the installation and launch description as well as to enjoy our recap that depicts basic user stories.

The programming code repository is located at GitLab repository. It can also be found in the documentation repository in section How to build up and use

You can find the screencast of and observe the basic user story.

NB: We noticed some technical troubles with the recent update of TON Crystal Wallet (v. 0.2.15). In some cases you will not be able to create DID if you had previous versions and updated to v. 0.2.15. However, newly created wallets work fine. Therefore, in case of troubles we advise you to reinstall the wallet.

Project credits: Alexey Vorobey, Stepan Gershuni, Arthur Pinchuk, Vladimir Kanin, Vyacheslav Zhuravlyov, Alexander Alexeenko, Nikita Lobushkin, Konstantin Agapotov, Yuliya Matsokina, Ildar Nurmukhametov, Anton Kirilyuk.


P.S. product scenarios are fictional. We do not imply that the mentioned services (Pokerton; Ton Swap; EasyVote) use our credential scheme and provide indicated bonuses and discounts.

Just in case, you may contact to our team via this Telegram account: @avarab