BlockID: One ID, Infinite Trust

BlockID: One ID, Infinite Trust

Project Highlights

BlockID is a decentralized identity and reputation protocol built on the Internet Computer, enabling users to build and verify their Web3 identity through various on-chain activities. It serves as a trust layer that:

  • Aggregates user’s on-chain activities across multiple providers (NNS, NFT, Ledger transactions and more…)
  • Generates a comprehensive trust score based on verified activities
  • Provides secure identity verification for dApps through Verifiable Credentials

Links

The Challenge

Bot Invasion in the IC Ecosystem

The Internet Computer ecosystem faces significant challenges from automated bots that:

  • Manipulate airdrops and token distributions
  • Exploit DeFi protocols through fake accounts
  • Inflate user metrics with phantom engagement
  • Drain project resources through fraudulent claims
  • Compromise fair launch mechanisms
  • Create artificial market movements
  • Overwhelm system resources with automated interactions

Identity Fragmentation

In the current Web3 ecosystem, particularly on the Internet Computer:

  • Users receive different principals for each dApp they interact with
  • There’s no way to link these identities or build a comprehensive reputation
  • dApps lack a standardized way to verify user identity and trustworthiness
  • Users have to rebuild their reputation from scratch for each application

Use Cases & Solutions

  1. Fair Token Distribution

    • Verify real users for airdrops
    • Prevent Sybil attacks
    • Ensure equitable resource allocation
  2. DeFi Protection

    • Bot-resistant trading mechanisms
    • Verified user pools
    • Trusted liquidity provision
  3. NFT Launch Security

    • Prevent mint sniping by bots
    • Prioritize verified collectors
    • Protect authentic community engagement
  4. DAO Governance

    • Ensure genuine community voting
    • Prevent vote manipulation
    • Weighted voting based on trust scores
  5. Community Building

    • Identify and reward genuine participants
    • Filter out automated engagement
    • Build trusted user networks

How It’s Built

BlockID consists of three main components:

  1. Block ID Root

    • Core canister managing identity verification and scoring
    • Integrates with multiple providers (NNS, NFT, Ledger)
    • Calculates and stores trust scores
  2. Issuer Canister

    • Handles Verifiable Credential issuance
    • Provides secure verification interface for dApps
    • Manages credential validation and revocation
  3. Provider Integration

    • Modular architecture for easy addition of new providers
    • Standardized scoring system
    • Real-time verification of on-chain activities

Our Solution

Identity Unification

  • Users authenticate through Internet Identity
  • BlockID links different principals under one unified identity
  • Maintains privacy while enabling reputation portability

Trust Score System

  • Transparent scoring mechanism based on verified activities
  • Weighted scoring across different providers
  • Time-based decay to ensure score relevancy

Customizable Validation Framework

  • Custom Validator Creation

    • dApps can create their own validators with unique criteria
    • Flexible scoring system adaptable to specific project needs
    • No dependency on BlockID’s fixed scoring metrics
  • Easy Integration Tools

    • No-code validator configuration interface
    • Simple API endpoints for quick implementation
    • Comprehensive documentation and templates

Future Roadmap

  • NFT credentials (ICRC-7) for achievement recognition
  • Enhanced privacy features
  • Expanded provider network
  • Advanced validator creation tools
  • Validator templates marketplace
  • Cross-project validation sharing

This is an open project, and we greatly welcome contributions from everyone :smiling_face_with_three_hearts:. The source code will be made available in a few days, along with some bridging solutions for projects currently using Motoko that wish to integrate with vc flow.

2 Likes

Hello. Sorry for asking but maybe someone from the dfinity team can answer this:

Is this 100% safe for us users when we were adding Canister ID of BlockID as your Neuron Hotkey?

Like are step 3+4 recommended?
Step 3: Find the “Hotkeys” section, add the Canister ID of BlockID as your Neuron Hotkey:

3c7yh-4aaaa-aaaap-qhria-cai

Step 4: Next, add your current wallet Principal as your Neuron Hotkey:

j2jp2-qhjne-fsmoz-q44nv-5xuo…

I am trying to be extra careful with my NNS ID and not sure what is safe and not.
Thank you and greetings!

BTW: i like the idea fighting against bots and farm users!

2 Likes

Here is a complete list of things someone with a hotkey to your neuron can do: What is a neuron? | Internet Computer

  • Voting
  • Following
  • Reading the full information about the neuron, including non-public fields
  • Submit a proposal (If someone submits spam proposals with your neuron they could drain the stake)

Hello severin, thank you for your quick response.
Another question (i couldnt find an answer by my own) Can somehing happen to our investment by logging in with our internet identity? i mean do we have to take care WHERE we login… (sure we should but can something happen if we dont) Can our SEED phrase or something else get stolen? There are so many new websites, dapps etc where i always need to log in via my identity… is it safe…? for sure i mean just the login process itself…

II is an identity provider that gives a separate identity for every* place you log in. If you log in at a different place it is not possible to use that login to do anything related to your NNS dapp login

* It is possible to share an identity across a few places, but it is clearly labelled as such in the login screen and the NNS dapp does not participate

heya @Fern.N
do you know about identitykit?
integration of this library can make it easier for you to integrate wallets/signers that support all existing IC signers standards.

1 Like

Thank you! NFID is fantastic, and we’re in the process of integrating NFID with the help of @dostro

1 Like

Update: BlockID sdk published: Seamless Integration for Your dApp!

We are thrilled to announce the release of our BlockID SDK, designed to make it easier than ever to integrate BlockID into your existing dApp systems. With this SDK, developers can now leverage the power of BlockID’s secure and decentralized identity solutions with just a few lines of code.

Installation

npm install @blockid/sdk

Quick Start

import { BlockID } from '@blockid/sdk';

// Initialize SDK
const blockID = new BlockID({
  host: 'https://icp0.io',// Optional, defaults to https://icp0.io
  appId: 'your-app-id'// Optional, defaults to 'block-id'
});

// Verify with BlockID, ensure your wallet is connected to your dApp
const result = await blockID.verifyScore({required: 10, principal: 'principal-id'});
console.log('Verification result:', result);

// Verify score with Internet Identity using VC Flow
const result = await blockID.verifyScore({required: 10, principal: 'principal-id', vcFlow: true});
console.log('Verification result:', result);

We will automatically verify it based on your input. Note that if you log in using Internet Identity for your dApp, declare vcFlow: true to seamlessly enable VC Flow.

Create your app on BlockID Dashboard and get your appId. Or use default appId and verify with BlockID.

More infomation and source code: BlockID/src/sdk at main · ICTO-Labs/BlockID · GitHub

This looks very cool! Can you give a 1000 foot view of how an app dev would use this to issue their own credential based on something in their canister?

Say I want to issue you a temporary credential that you own an nft but you are verifying it in another site where you have a diff principal. How does that work?

1 Like

Thank you!
Currently, on the Internet Computer ecosystem, there’s an issue as you mentioned: Internet Identity generates completely different principals for each dApp. Therefore, I’ll break this down into two scenarios:

For users using standard wallets (with a consistent principal, like Oisy, Plug, NFID, etc.):
You’ll need to create a function with a predefined interface (see below). BlockID will call this function via our Remote Provider to verify the principal (for a consistent principal).

module {
    public type VerificationResult = {
            score : Nat;
            message : Text;
            isValid : Bool;
    };
    public type Self = actor {
            verify : shared Principal -> async VerificationResult;
    }
}

Documents: Block ID | One ID - Infinite Trust

For users using Internet Identity and logging into your dApp:
In this case, the principal in your dApp will differ from the principal in BlockID. Therefore, your dApp will act as the Issuer, and BlockID will act as the Relying Party, with verification happening through the VC Flow.

We also recognize that building an Issuer or Relying Party can be quite complex. Additionally, VC Flow isn’t officially supported in Motoko yet, which is a limitation for projects built on this language. To address this, we’re learning and improving by building Bridge Issuers (built in Rust), similar to what BlockID is doing. This allows dApps to simply provide a public/private function following a standardized interface and return data with the principal generated in their dApp. We’ll handle the rest of the verification process.

I’m also new to Rust, so I’d greatly appreciate feedback and suggestions from experts to improve further!

What do we need to build in motoko to get it to work there?

For both cases, from your motoko canister, you need add public function according to the specified interface and create verification logic.

    // Verify function that BlockID can call
    public shared({caller}) func verify(walletId: Principal) : async VerificationResult {
        // if (Principal.toText(caller) != blockIDCanister) {
        //     return {
        //         isValid = false;
        //         score = 0;
        //         message = "Unauthorized caller";
        //     };
        // };

        //Your verify logic....
        if (isWhitelisted(walletId)) {
            return {
                isValid = true;
                score = 100;
                message = "Wallet is whitelisted";
            };
        };

        return {
            isValid = false;
            score = 0;
            message = "Your wallet is not whitelisted!";
        };
    };

Example canister: BlockID/src/whitelist/main.mo at main · ICTO-Labs/BlockID · GitHub

In case “For users using standard wallets” is working fine, we are testing and releasing the Issuer bridge version soon (for Internet Identity login)