Getting Started with IOTA Identity

Share This Post

by Pascal Gottret


After reading the first few articles from the Tangle Labs Blog, you should now have a good idea of what SSI (self-sovereign identity) is, how it can help to solve the problems of the “Web2” world, and some of the use cases where SSI can provide novel solutions. In this article, we will explain the technical details of how SSI and its elements work. We will also discuss how to get started with the technology using the IOTA Identity Protocol (a framework built by the IOTA Foundation).

As described in the introduction to SSI, SSI is about shifting control of data from a central organisation and verifier to the identity subject (i.e., an entity, a person, organisation, or object for whom the identity is created). They (the subject) can then control how their data is shared and used. Achieving this crucial step towards privacy requires accurate application of the basic building blocks of SSI. These blocks include verifiable data registries (VDR), the trust triangle (issuer, holder, and verifier), digital wallets and agents, decentralised identifiers (DIDs), verifiable credentials (VCs), and the governance framework. While the trust triangle, wallets, and governance framework are already covered in other articles, this article focuses on the technical explanation and application of the VDR, DIDs, and VCs.

Explaining VDR, DIDs and VCs

The verifiable data registry and introduction to the IOTA DLT

For an SSI ecosystem involving different actors communicating with one another, it is crucial to have a common public storage location to retrieve important information about identities. In SSI terms, a public storage is called a verifiable data registry (VDR).

There are several ways to set up a VDR. For instance, you can build a conventional database or you may use a distributed ledger technology (DLT) implementation such as a blockchain or the IOTA Tangle. The latter refers to a:

“…distributed network of participants that replicate, share, and synchronize digital data and value spread across many different locations. Unlike with a centralized database, there is no central administrator.”
– Permissionless Innovation – How to enhance your business with IOTA, 2022

One of the emerging DLTs, although not a classical blockchain, is the IOTA protocol. It uses a different technical basis, called a directed acyclic graph (DAG), that allows parallel processing of transactions. Its main goal is to provide a generally usable, scalable, interoperable and energy-efficient network, with its main difference compared to classical blockchain protocols is the absence of miners and thus third-party validators collecting transaction fees. IOTA is a secure permissionless network which allows users to make data transfers as well as value transfers. In the context of SSI, this allows you to write identities on the public ledger without using tokens.

Preukschat and Reed (2021) evaluated the possibility of using DLT towards achieving SSI as follows: DLT solves “a problem that has never had a solution in the history of cryptography: how a globally distributed database can serve as a source of truth for public keys without being subject to single points of failure or attack.”

The permissionless, feeless and secure nature of the IOTA protocol is a perfect fit for a VDR to store decentralized identifiers (DID) in a secure and tamper-proof manner on the ledger without relying on a central trusted authority.

Decentralized identifiers

A Decentralized Identifier (DID) is basically a new type of a globally unique identifier. You can compare it to the URL we use when browsing on the internet, e.g, https://tanglelabs.io. Each actor – people, organizations, things – in the SSI ecosystem will have its own DID. This DID is a text string containing the scheme, the DID method (resolving to the VDR; for example, IOTA in our example below), and a unique string within that method.

Figure 2 Example of a decentralized identifier on IOTA

A DID always includes a public and private key. While the public keys of a DID, which signs credentials is stored on the VDR (i.e. the IOTA DLT), the private key is stored in the holder’s wallet. With this combination, the holder – and only the holder – is able to cryptographically prove that they are the controller of the DID. The identifier is strongly tied to them.

Figure 3: an example how the DID controls the private and public key

So far we have learned that the DID is a unique identifier, but how can other parties use, or “resolve” in SSI-terms, this identifier? How can the verifier obtain the issuer’s public key to verify the issuer’s signature and what proof does the verifier have that the public key belongs to the issuer?

To achieve this, each DID controls one signed DID document and publishes it to the VDR, proving that the DID is in control of the public key. This is where the VC completes a full circle: the public key is strongly bound to the identifier. The verifier (verifying a particular credential) resolves the issuer’s DID document on the VDR, receives information about the public key and the verification method, and is able to cryptographically verify the signature in the VC.

did:iota:GYmbp6c5G77NhGSJJ5byNUj62nQEuGHAzQ2ikSGMr1jD{  "doc": {    "id": "did:iota:GYmbp6c5G77NhGSJJ5byNUj62nQEuGHAzQ2ikSGMr1jD",    "capabilityInvocation": [      {        "id": "did:iota:GYmbp6c5G77NhGSJJ5byNUj62nQEuGHAzQ2ikSGMr1jD#sign-0",        "controller": "did:iota:GYmbp6c5G77NhGSJJ5byNUj62nQEuGHAzQ2ikSGMr1jD",        "type": "Ed25519VerificationKey2018",        "publicKeyMultibase": "zAs84e72rbkhdCtAgLGsqEVSq3Kv7dYzjAwmhBRcdi6KS"      }    ]  },  "meta": {    "created": "2022-04-05T19:52:52Z",    "updated": "2022-04-05T19:52:52Z"  }}

Compared with other unique identifiers, such as DNS, DIDs come with four core properties that set them apart:

  1. A DID is a permanent identifier
  2. A DID is publicly resolvable
  3. A DID is cryptographically verifiable (proof of control using cryptography)
  4. A DID is decentralized (no central registry is required)

People might mistakenly think that DIDs have the same functionality as traditional Public Key Infrastructure (PKI) solutions. Upon closer inspection, you will see that the four core principles listed above matter a lot in fully trusted environments. While traditional PKI-solutions rely on trusted third parties (TTP) and central authorities (CA), such as X.509 certs, DIDs do not. To ensure that the counterpart is trustworthy, DIDs solve two core problems:

  1. How do you strongly bind the identifier to the controller of the identity?
  2. How do you strongly bind the public key to the identifier?

In other words, DID enables a trusted environment without the need for third-party intervention.

A further advantage of DID is the possibility to update the public key in the DID Document by uploading the new version of the DID Document (to the VDR) and signing it with the former private key. Changing public keys is a strong method for enhanced security. especially in the event of data breaches.

Verifiable credentials

As explained in the introduction article, credentials are a set of claims about the DID subject of the credential and, in terms of SSI, are issued in in form of a verifiable credential (VC) that is cryptographically signed by its issuer. Digital credentials are intended to provide information about who issued the credential, whether it contains the data required by the verifier, whether it has been tampered with, and whether it is still valid.

As of today, there are primarily four data formats for verifiable credentials (VC):

  • JSON Web Token (JWT)
  • JSON-LD with LD-Signatures
  • Zero Knowledge Proofs (ZKP) with Camenisch-Lysyanskaya Signatures (ZKP-CL)
  • JSON-LD ZKP with BBS+ Signatures

Each of these formats comes with advantages and disadvantages regarding:

  • Simplicity: Programming and readability.
  • Selective disclosure: is the holder able to prove only parts of a VC or do they have to reveal the full VC?
  • ZKP: A method used in cryptography to prove that something is known without directly revealing the known information. ZKPs are indirect evidence that can be used to prove that you know a secret without ever revealing the secret to another person.
  • Reveal persistent identifier: Necessity to include the identifier of the holder (DID) in order to prove the legitimacy of the VC.
  • Semantic disambiguation: is the VC semantically interpretable?


JSON Web Token (JWT)





Simplest among all

Relatively simple

Most complicated among all


Privacy Preserving





Selective Disclosure









Not yet

Need to reveal persistent identifier





Semantic Disambiguation





Figure 4: Comparison table for current formats of Verifiable Credential.

Privacy preservation is what SSI aims to achieve. VC formats with support of ZKP are able to prove a set of claims without disclosing its actual content. Each claim gets its own cryptographic signature. On the other hand, VC formats without support of ZKP do not hide its content and the cryptographic signature signs the full VC.

Does this mean that only VC with ZKP support shall be applied, since the other formats do not support privacy sufficiently? No, not necessarily. There are situations where legal frameworks require an audit trail of credentials used, such as in the finance sector with “Know Your Customer”.

Currently, the IOTA Identity Protocol supports JSON-LD. With ZKP-CL and JSON-LD with BBS+ signatures under research and prototyping.

Example of a verification process

Let’s look at an example of how the procedure of verifying a credential might look like. Imagine you are applying for a new apartment and the landlord requires the tenant to have a regular income. Therefore, you need to provide a certificate of employment from your employer. Using SSI (DIDs and VC), the procedure is as follows:

  1. You create a new identity (DID) in your digital wallet (on your cell phone) and store the DID document on the IOTA ledger.
  2. You establish an encrypted peer-to-peer connection with your employer, who in turn has stored his own DID in a public ledger.
  3. The employer creates a VC for your DID (specifying that you indeed work at that particular company) and signs it with her private key, and your mobile wallet safely stores the credential inside it.
  4. You want to show the credential to the landlord, who is the verifier of your credential. You first create an encrypted peer-to-peer connection with him. Afterwards, your mobile wallet creates a VP with the necessary information. The VP is signed by your private key and presented to the verifier.
  5. Your landlord scans the credential. His mobile wallet first checks the signature of the VP to make sure that you are the holder of the DID. He then reads the DID of the issuer (i.e., your employer) and resolves its DID Document. His wallet is now able to verify that the credential contains the necessary information and that the signature is valid, by looking up the issuer’s public key and verification method.
  6. Because the verifier has a proof of integrity of the credential, meaning he can know for sure that the credential is genuine, you can now sign the rental agreement – and you are the legitimate tenant for the apartment. No need to mention that this comes with a VC from the landlord to your mobile wallet!

Revoking a VC

A credential might need to be revoked for various reasons: the credentials might be expiring, certain VCs might have been issued in error, or for any other reason that an issuer sees fit. Therefore, it is necessary to include functionalities in the SSI framework that allows the verifier to verify a revocation without having to contact the issuer.

There are several ways to accomplish this goal (cryptographic accumulators, revocation list, credential status, etc.). One way to revoke a VC is to change the verification method (public key) within the DID document. If the issuer’s public key has been changed, the verifier will no longer be able to verify the VC’s signature, indicating to the verifier that the credential is no longer valid.

How to use IOTA Identity

Now that you have a technical overview of how VDR, DIDs, and VCs are connected, let’s see how we can use this technology atop the IOTA distributed ledger. To do this, we’ll use the IOTA identity protocol. First, we have to install all prerequisites on our computer. Next, we create our own identity using pre-made examples, resolve it in the IOTA ledger, and make an update. Finally, we can create a VC.


In order to use the IOTA Identity framework, we need a machine running on Windows, Linus or MacOS – the following process is explained assuming we’re operating on a Linux machine.

The IOTA Identity framework is available on Github at https://github.com/iotaledger/identity.rs (v. 0.5). There are two ways to install and use it: Either with the programming language RUST or with the built-in WASM bindings, which allows us to run all the commands in JavaScript.

In the repository, an encrypted storage called IOTA Stronghold is included. In a real world case, a secure key storage solution is important to support the safe storage of your keys. You can learn more about the IOTA stronghold here https://blog.iota.org/iota-stronghold-6ce55d311d7c/. In this guide we want to include the opportunity to include the secure storage in our examples.

Please follow the instructions after having connected to your machine:

  1. If not installed already, install git:
sudo apt-get install git

2. Navigate to the folder where you want to install the IOTA Identity repository. In our case, we use

cd /var/lib/

3. Install the IOTA Identity framework

sudo git clone https://github.com/iotaledger/identity.rs

For RUST installation, continue here. For WASM please jump to step 7.

4. Install Rust and Cargo: run

sudo curl https://sh.rustup.rs -sSf | sh 

this install might take some time, for further information, visit https://www.rust-lang.org/tools/install.

5. Go into the identity.rs folder

cd identity.rs

6. Build the cargo

cargo build

to download all dependencies please ensure you have the necessary authorizations; if you get a “permission denied” error, go back to /var/lib/ and execute

sudo chmod 777 identity.rs

WASM binding (JavaScript)

7. Do not forget to update your existing packages.

sudo apt-get update

8. In some cases, fixes are needed.

sudo apt --fix-broken install

9. Install Node.js and npm. Make sure that at least v. 16.0.0. is installed. Visit https://github.com/nodesource/distributions/blob/master/README.md for further instructions on how to update Node.js.

sudo apt install nodejssudo apt install npm

10. Install the libraries for WASM and Stronghold.

npm install @iota/identity-wasmnpm install @iota/identity-stronghold-nodejs

11. Go into folder bindings/wasm/

cd bindings/wasm/

12. Install the necessary dependencies.

npm install

13. Build the bindings for node.js.

npm run build:nodejs

14. In the folder /examples/src replace


imports with


for Node.js.

You are now ready to work with the IOTA Identity framework.

Creating a DID (without safely storing the private key)

Now that you have installed all the prerequisites, you will be able to create your own identity.

In Shell, run (RUST)

cargo run --example create_did

or (JavaScript)

npm run example:node -- create_did

Further dependencies might be necessary and will be downloaded and compiled automatically. After a while, you should see your DID Document. The output looks like the example shown below.

DID Document Transaction: https://explorer.iota.org/mainnet/message/d26cbf4e298a521e97eae1ecb195cf8fc43ed0d0eeb9763dcebea5c187e88d27Explore the DID Document: https://explorer.iota.org/mainnet/identity-resolver/did:iota:9zZZvvMaRXK2dKXxCi2BKnqCpBKE5hS8UK8eAZEKJQuiOk > {	key: {		type: 'ed25519',		public: '9a1Mmkqav6ePZMb1WdAxgBCNBdAZx1srXorhMBMhd9FE',		private: '...'		 },	doc: {		doc: {			id: 'did:iota:9zZZvvMaRXK2dKXxCi2BKnqCpBKE5hS8UK8eAZEKJQui',			capabilityInvocation: [Array]		 },	meta: {		created: '2022-04-05T20:24:02Z',		updated: '2022-04-05T20:24:02Z',	proof: [Object]		  }},receipt: {	network: 'main',	messageId: 	'd26cbf4e298a521e97eae1ecb195cf8fc43ed0d0eeb9763dcebea5c187e88d27',	networkId: 1454675179895816200,	nonce: 2236363	}}

Congratulations! You have successfully created your first identity.

This action generates your public and private keys.

Creating DID (with safely storing the private key)

In the folder


create a new file


and paste the following code (replacing the password):

const { AccountBuilder, ExplorerUrl } = require('@iota/identity-wasm/node')const { Stronghold } = require('@iota/identity-stronghold-nodejs')async function main() {	// Stronghold settings for the Account storage.	// This will load an existing Stronghold or create a new one 	automatically.	const filepath = "./example-strong.hodl";	const password = "my-password";	const stronghold = await Stronghold.build(filepath, password);	// This generates a new keypair stored securely in the above Stronghold,	// constructs a new DID Document, and publishes it to the IOTA Mainnet.	let builder = new AccountBuilder({	storage: stronghold,	});	let account = await builder.createIdentity();	// Print the DID of the newly created identity.	const did = account.did();	console.log(did.toString());	// Print the local state of the DID Document.	const document = account.document();	console.log(JSON.stringify(document, null, 2));	// Print the Explorer URL for the DID.	console.log(`Explorer URL:`, ExplorerUrl.mainnet().resolverUrl(did));}main()

Now run the command

sudo node create_did.js

Your DID will be created and the private key safely secured in the file


Resolving a DID

In order to resolve a DID, run (RUST)

cargo run --example resolve

or (JavaScript)

npm run example:node -- resolution

Please note that this example first creates a new DID document, which is then resolved. To use the same DID you first created, edit the example above to safely store your keys and retrieve them to resolve a DID.

Updating DID

In order to update DID, run (RUST)

cargo run --example manipulate_did

or (JavaScript)

npm run example:node -- manipulate_did

Again, change the examples to reuse your DID accordingly.

Create a VC

This example includes a University Degree credential in JSON format. Feel free to change it in any other form of credential.

In order to create a VC, run (RUST)

cargo run --example create_vc

or (JavaScript)

npm run example:node -- create_vc

Again, change the examples to reuse your DID accordingly.


A demonstration of the easily accessible nature of Identity, this article has highlighted, from a technical perspective, how the key elements of an SSI ecosystem (VDR, VC and DID) can function and interact with each other, using the IOTA Identity Protocol. Illustrating the accessible nature of the open technology, through just a few easy-to-follow steps it is available for anyone, anywhere to integrate and use in their developments. This simplicity and free use of open-source solutions such as IOTA Identity provides a solid foundation for a gradual achievement of market maturity towards the more widely adopted use of SSI. Why not give it a go!?

More To Explore

CCTV cameras on concrete wall

eID and SSI technology: privacy risks and discrimination against citizens?

In addition to the enormous advantages offered by SSI, it is also important to bear in mind that there are dangers lurking for citizens with the digitization of identities. Critics present very valid arguments against the widespread introduction of this technology in society. At this point, I will address these points.

Identity Manager Release

Identity Manager – Self Sovereign Identity made Simple

Self-Sovereign Identity development experts Tangle Labs have just released the latest version of their open-source Identity Manager libraries that provide accessible development tools for businesses and organisations to create anything with Identity.

Terms Of Use

Welcome to Tangle Labs Website!

These terms and conditions outline the rules and regulations for the use of Tangle Labs UG’s Website, located at tanglelabs.io.

By accessing this website we assume you accept these terms and conditions. Do not continue to use Tangle Labs Website if you do not agree to take all of the terms and conditions stated on this page.

The following terminology applies to these Terms and Conditions, Privacy Statement and Disclaimer Notice and all Agreements: “Client”, “You” and “Your” refers to you, the person log on this website and compliant to the Company’s terms and conditions. “The Company”, “Ourselves”, “We”, “Our” and “Us”, refers to our Company. “Party”, “Parties”, or “Us”, refers to both the Client and ourselves. All terms refer to the offer, acceptance and consideration of payment necessary to undertake the process of our assistance to the Client in the most appropriate manner for the express purpose of meeting the Client’s needs in respect of provision of the Company’s stated services, in accordance with and subject to, prevailing law of Switzerland. Any use of the above terminology or other words in the singular, plural, capitalization and/or he/she or they, are taken as interchangeable and therefore as referring to same.


We employ the use of cookies. By accessing Tangle Labs Website, you agreed to use cookies in agreement with the Tangle Labs UG’s Privacy Policy.

Most interactive websites use cookies to let us retrieve the user’s details for each visit. Cookies are used by our website to enable the functionality of certain areas to make it easier for people visiting our website. Some of our affiliate/advertising partners may also use cookies.


Unless otherwise stated, Tangle Labs UG and/or its licensors own the intellectual property rights for all material on Tangle Labs Website. All intellectual property rights are reserved. You may access this from Tangle Labs Website for your own personal use subjected to restrictions set in these terms and conditions.

You must not:

  • Republish material from Tangle Labs Website
  • Sell, rent or sub-license material from Tangle Labs Website
  • Reproduce, duplicate or copy material from Tangle Labs Website
  • Redistribute content from Tangle Labs Website


Parts of this website offer an opportunity for users to post and exchange opinions and information in certain areas of the website. Tangle Labs UG does not filter, edit, publish or review Comments prior to their presence on the website. Comments do not reflect the views and opinions of Tangle Labs UG, its agents and/or affiliates. Comments reflect the views and opinions of the person who post their views and opinions. To the extent permitted by applicable laws, Tangle Labs UG shall not be liable for the Comments or for any liability, damages or expenses caused and/or suffered as a result of any use of and/or posting of and/or appearance of the Comments on this website.

Tangle Labs UG reserves the right to monitor all Comments and to remove any Comments which can be considered inappropriate, offensive or causes breach of these Terms and Conditions.

You warrant and represent that:

  • You are entitled to post the Comments on our website and have all necessary licenses and consents to do so;
  • The Comments do not invade any intellectual property right, including without limitation copyright, patent or trademark of any third party;
  • The Comments do not contain any defamatory, libellous, offensive, indecent or otherwise unlawful material which is an invasion of privacy
  • The Comments will not be used to solicit or promote business or custom or present commercial activities or unlawful activity.

You hereby grant Tangle Labs UG a non-exclusive license to use, reproduce, edit and authorize others to use, reproduce and edit any of your Comments in any and all forms, formats or media.

Hyperlinking to our Content

The following organizations may link to our Website without prior written approval:

  • Government agencies;
  • Search engines;
  • News organizations;
  • Online directory distributors may link to our Website in the same manner as they hyperlink to the Websites of other listed businesses; and
  • System wide Accredited Businesses except soliciting non-profit organizations, charity shopping malls, and charity fundraising groups which may not hyperlink to our Web site.

These organizations may link to our home page, to publications or to other Website information so long as the link: (a) is not in any way deceptive; (b) does not falsely imply sponsorship, endorsement or approval of the linking party and its products and/or services; and (c) fits within the context of the linking party’s site.

We may consider and approve other link requests from the following types of organizations:

  • commonly-known consumer and/or business information sources;
  • dot.com community sites;
  • associations or other groups representing charities;
  • online directory distributors;
  • internet portals;
  • accounting, law and consulting firms; and
  • educational institutions and trade associations.

We will approve link requests from these organizations if we decide that: (a) the link would not make us look unfavourably to ourselves or to our accredited businesses; (b) the organization does not have any negative records with us; (c) the benefit to us from the visibility of the hyperlink compensates the absence of Tangle Labs UG; and (d) the link is in the context of general resource information.

These organizations may link to our home page so long as the link: (a) is not in any way deceptive; (b) does not falsely imply sponsorship, endorsement or approval of the linking party and its products or services; and (c) fits within the context of the linking party’s site.

If you are one of the organizations listed in paragraph 2 above and are interested in linking to our website, you must inform us by sending an e-mail to Tangle Labs UG. Please include your name, your organization name, contact information as well as the URL of your site, a list of any URLs from which you intend to link to our Website, and a list of the URLs on our site to which you would like to link. Wait 2-3 weeks for a response.

Approved organizations may hyperlink to our Website as follows:

  • By use of our corporate name; or
  • By use of the uniform resource locator being linked to; or
  • By use of any other description of our Website being linked to that makes sense within the context and format of content on the linking party’s site.

No use of Tangle Labs UG’s logo or other artwork will be allowed for linking absent a trademark license agreement.


Without prior approval and written permission, you may not create frames around our Webpages that alter in any way the visual presentation or appearance of our Website.

Content Liability

We shall not be hold responsible for any content that appears on your Website. You agree to protect and defend us against all claims that is rising on your Website. No link(s) should appear on any Website that may be interpreted as libellous, obscene or criminal, or which infringes, otherwise violates, or advocates the infringement or other violation of, any third party rights.

Your Privacy

Please read our Privacy Policy

Reservation of Rights

We reserve the right to request that you remove all links or any particular link to our Website. You approve to immediately remove all links to our Website upon request. We also reserve the right to amen these terms and conditions and it’s linking policy at any time. By continuously linking to our Website, you agree to be bound to and follow these linking terms and conditions.

Removal of links from our website

If you find any link on our Website that is offensive for any reason, you are free to contact and inform us any moment. We will consider requests to remove links but we are not obligated to or so or to respond to you directly.

We do not ensure that the information on this website is correct, we do not warrant its completeness or accuracy; nor do we promise to ensure that the website remains available or that the material on the website is kept up to date.


To the maximum extent permitted by applicable law, we exclude all representations, warranties and conditions relating to our website and the use of this website. Nothing in this disclaimer will:

  • limit or exclude our or your liability for death or personal injury;
  • limit or exclude our or your liability for fraud or fraudulent misrepresentation;
  • limit any of our or your liabilities in any way that is not permitted under applicable law; or
  • exclude any of our or your liabilities that may not be excluded under applicable law.

The limitations and prohibitions of liability set in this Section and elsewhere in this disclaimer: (a) are subject to the preceding paragraph; and (b) govern all liabilities arising under the disclaimer, including liabilities arising in contract, in tort and for breach of statutory duty.

As long as the website and the information and services on the website are provided free of charge, we will not be liable for any loss or damage of any nature.

Privacy Policy

Here at the Tangle Labs Website, accessible from tanglelabs.io, one of our main priorities is the privacy of our visitors. This Privacy Policy document contains types of information that is collected and recorded by Tangle Labs Website and how we use it.

If you have additional questions or require more information about our Privacy Policy, do not hesitate to contact us.

This Privacy Policy applies only to our online activities and is valid for visitors to our website with regards to the information that they shared and/or collect in Tangle Labs Website. This policy is not applicable to any information collected offline or via channels other than this website. .


By using our website, you hereby consent to our Privacy Policy and agree to its terms.

Information we collect

The personal information that you are asked to provide, and the reasons why you are asked to provide it, will be made clear to you at the point we ask you to provide your personal information.

If you contact us directly, we may receive additional information about you such as your name, email address, phone number, the contents of the message and/or attachments you may send us, and any other information you may choose to provide.

When you register for an Account, we may ask for your contact information, including items such as name, company name, address, email address, and telephone number.

How we use your information

We use the information we collect in various ways, including to:

  • Provide, operate, and maintain our website
  • Improve, personalize, and expand our website
  • Understand and analyse how you use our website
  • Develop new products, services, features, and functionality
  • Communicate with you, either directly or through one of our partners, including for customer service, to provide you with updates and other information relating to the website, and for marketing and promotional purposes
  • Send you emails
  • Find and prevent fraud

Log Files

Tangle Labs Website follows a standard procedure of using log files. These files log visitors when they visit websites. All hosting companies do this and a part of hosting services’ analytics. The information collected by log files include internet protocol (IP) addresses, browser type, Internet Service Provider (ISP), date and time stamp, referring/exit pages, and possibly the number of clicks. These are not linked to any information that is personally identifiable. The purpose of the information is for analysing trends, administering the site, tracking users’ movement on the website, and gathering demographic information.

Cookies and Web Beacons

Like any other website, Tangle Labs Website uses ‘cookies’. These cookies are used to store information including visitors’ preferences, and the pages on the website that the visitor accessed or visited. The information is used to optimize the users’ experience by customizing our web page content based on visitors’ browser type and/or other information.

For more general information on cookies, please read the Cookies article on Generate Privacy Policy website.

Third Party Privacy Policies

Tangle Labs Website’s Privacy Policy does not apply to other advertisers or websites. Thus, we are advising you to consult the respective Privacy Policies of these third-party ad servers for more detailed information. It may include their practices and instructions about how to opt-out of certain options.

You can choose to disable cookies through your individual browser options. To know more detailed information about cookie management with specific web browsers, it can be found at the browsers’ respective websites.

CCPA Privacy Rights (Do Not Sell My Personal Information)

Under the CCPA, among other rights, California consumers have the right to:

Request that a business that collects a consumer’s personal data disclose the categories and specific pieces of personal data that a business has collected about consumers.

Request that a business delete any personal data about the consumer that a business has collected.

Request that a business that sells a consumer’s personal data, not sell the consumer’s personal data.

If you make a request, we have one month to respond to you. If you would like to exercise any of these rights, please contact us.

GDPR Data Protection Rights

We would like to make sure you are fully aware of all of your data protection rights. Every user is entitled to the following:

The right to access – You have the right to request copies of your personal data. We may charge you a small fee for this service.

The right to rectification – You have the right to request that we correct any information you believe is inaccurate. You also have the right to request that we complete the information you believe is incomplete.

The right to erasure – You have the right to request that we erase your personal data, under certain conditions.

The right to restrict processing – You have the right to request that we restrict the processing of your personal data, under certain conditions.

The right to object to processing – You have the right to object to our processing of your personal data, under certain conditions.

The right to data portability – You have the right to request that we transfer the data that we have collected to another organization, or directly to you, under certain conditions.

If you make a request, we have one month to respond to you. If you would like to exercise any of these rights, please contact us.

Children’s Information

Another part of our priority is adding protection for children while using the internet. We encourage parents and guardians to observe, participate in, and/or monitor and guide their online activity.

Tangle Labs Website does not knowingly collect any Personal Identifiable Information from children under the age of 13. If you think that your child provided this kind of information on our website, we strongly encourage you to contact us immediately and we will do our best efforts to promptly remove such information from our records.