Talent Protocol is an open protocol for onchain reputation data. Our protocol and API make it easy to integrate verified builder reputation into any application.

What You Can Build

• Identity & Auth: Add reputation-based context and authentication to your app.

  • Examples: Basenames and Etherscan

• Search & Discovery: Find top builders based on verified reputation data

  • Examples: Veew.ai and Talent App

• Reputation Systems: Create custom scoring systems using our data primitives.

  • Example: Moxie

Quick Start

1. Get your API key by opening filling this form.

2. Make your first API call: https://api.talentprotocol.com/api/v2/

3. Explore our API Reference or jump into specific guides:

   • Authentication

   • Builder Score

   • Smart Contracts

Core Concepts

Talent Protocol is built on composable primitives:

• Accounts: Third-party data connections (like wallets, GitHub, X) that feed verified reputation data into the protocol

• Data Points: Objective, verifiable facts about builders

• Events: Historical records of reputation changes

• Scoring Systems: Customizable frameworks for evaluating someone's reputation

Learn more in our Core Concepts guide.

Support

• Join our Discord and Farcaster for technical support

• Follow @TalentProtocol for updates

Ready to start building? Let's make great builders stand out together. 🫡

X-API-KEY

The API key is the entry point for the Talent Protocol API. In order to perform requests it needs to be passed on every request.

We use the header X-API-KEY to retrieve the access key and validate your access to our API.

There're two types of API keys:

• read_only: Can only access GET requests

• write: Can access all requests

How to request an API key

Key Attributes:

• A Data Point provides a verified fact about a user's reputation at a given point in time.

• A Data Issuer can have multiple Data Points, but a Data Point only has one Data Issuer.

• A Data Point only contains objective and verifiable data.

• A Data Point doesn't store any scoring information; they can be use in multiple scoring systems.

• Example:

  • Data Issuer: GitHub

  • Data Point: Stars

  • Value: [number of stars]

Variable and Immutable Data Points:

• Immutable data points are simpler versions of variable data points.

• Variable Data Points contain a value that can change over time.

  • Example: GitHub Stars, ETH Balance on Base

• Immutable Data Points are only set once, and never recalculated again.

  • Example: Base Learn, KYC, First Transaction on Base

Categories of Data Points:

• Identity: Validates the user as a real human (e.g., WorldID).

• Activity: Demonstrates participation, engagement and consistency (e.g., number of transactions).

• Credibility: General indicators of trust, influence, and reliability (e.g., social media followers).

• Skills: Evidence of expertise and capabilities in specific domains (e.g., Developer, Creator).

API Key Rate Limits

• For free users, API usage is subject to 5,000 requests/month.

IP Rate Limits

• Each IP address has a maximum of 25 requests in 10 seconds.

Fair Use Policy

The following activities are prohibited:

• Excessive Use: Overuse of the API beyond the designated limits that impacts system performance or fairness for other users.

• Automated Abuse: Using scripts, bots, or automated tools to excessively query the API, harvest data, or engage in any behavior that could overload our systems.

• Redistribution: Reselling, sublicensing, or sharing your API Key with unauthorized third parties is strictly prohibited.

• Data Misuse: Manipulating, distorting, or misrepresenting the data obtained from our API, or using the data for illegal purposes.

Inactivity Clause

• We reserve the right to deactivate or cancel an API Key if it has been inactive for more than 30 consecutive days. Inactivity is defined as no API requests made during this period. If your API Key is deactivated due to inactivity, you may need to request a new key or contact support for reinstatement.

How it works

In order to paginate requests API consumers will need to check the pagination field inside each response.

Check the following response example:

In order to fetch the next page a new request will need to be performed with the page query param being passed as the current_page + 1.

You will reach the last page when the current_page is equal to the last_page.

You can learn more about this in the next chapter.

Key Attributes:

• Represents the source of trust for the data (e.g., GitHub, Base, ENS).

Examples:

• GitHub is both an Account (where we get the data from technically) and the Data Issuer (entity that we trust to issue reputation data to a subject).

• Base is a Data Issuer, with multiple Data Points (number of transactions, smart contracts deployed, ...), but it's not an Account. The account in this case is the wallet address.

Talent Registry

• An onchain record of Talent accounts created and the respective wallet address.

$TALENT Token

• The utility token for Talent Protocol that incentivizes ecosystem participants to verify reputation data.

Builder Score Onchain

• An onchain snapshot of the Builder Score of a given Talent ID and wallet address.

• Developers can query the Builder Score of all user via the Talent API, but also access the Builder Score of Builder+ members onchain, via a custom contract.

Key Attributes:

• Each user has a unique identifier (UUID) in the Talent database, ensuring every user is distinct.

• Users have a single profile URL aggregating data from all associated accounts.

  • talentprotocol.com/UUID

• A user is be able to sign-in to the Talent Protocol App with any account that they connected.

• For now, only the Talent Protocol app can create, update or delete users from the database. Ecosystem apps can only read data.

Types of Users:

• User: when we mention the term "user", we're referring to all individuals who signed up at talentprotocol.com, even if they haven’t connected a wallet or other accounts yet.

• Onchain User: Users with a verified EVM address added to the onchain Talent Registry.

• Paying User: Users who have spent funds on Talent Protocol, via the app or smart contracts.

• Private User: Users hidden from the app and API outputs, but still present in the database.

An Account represents a connection with a third-party entity (e.g., Wallet Address, GitHub, X, LinkedIn) that feeds reputation data into Talent Protocol. Accounts can exist independently or be linked to a user.

Key Attributes:

• Accounts have Account IDs (previously know as Passport ID) and account-specific URLs (until they're linked to a user), following this format:

  • talentprotocol.com/address/0xbd…23d4

  • talentprotocol.com/github/filmacedo

• If linked to a user, the account URL will automatically redirect to the user’s profile URL. Otherwise, it will show the data from that imported account independently.

• Users can claim an imported account by verifying ownership (e.g., signing a wallet message, connecting GitHub).

Types of Accounts:

• Indexed Account: All accounts being tracked by Talent Protocol, whether connected by users or imported automatically.

• Imported Account: Public accounts indexed directly by Talent Protocol, without any explicit user action, such as curated wallet addresses or public GitHub profiles.

• Connected Account: Accounts actively linked to a user’s profile and with verified ownership.

Talent Protocol intentionally separates Data Points (objective data) from Scoring Systems (subjective data). Both are autonomous and composable protocol primitives.

Scoring Framework

A Scoring System is composed of:

1. a selection of Data Points to be considered for this particular score

2. a value conversion (optional) to normalize Data Point values (ex.timestamp_to_year or sqrt)

3. a signal strength (strong, medium, or weak) attributed to each Data Point

4. a maximum score (in "points") that each Data Point can contribute to the overall score

5. a scoring function or condition that converts the current value of a Data Point into a numerical score (measured in "points")

Scoring systems are absolute, meaning they don’t include any form of normalization or percentile-based approach. The final score should be a simple sum of all Data Point individual scores.

This framework intends to keep every scoring system simple, transparent and scalable.

Calculating a Score

To calculate a score, Talent Protocol will follow the steps below:

1. Fetch new data for each account and store them in the respective Data Point.

3. We then apply the scoring framework to all Data Points with a value change.

   1. If there are multiple sources for the same data point (example: a user with multiples wallet addresses), we pick the one with the highest value.

What is the Builder Score?

Builder Score is a numerical value that represents a user's reputation as an onchain builder.

The Builder Score aims to distinguish builders from other types of crypto users, by valuing both the quantity and quality of their contributions. It reflects both "potential" (future growth) and "achievements" (proven track record).

Users can leverage their Builder Score within Talent Protocol's growing partner ecosystem, while developers can easily add the Builder Score to their apps.

The "Builder Score" Scoring Framework

1. value conversion

2. signal strength

3. max score

4. multiplier

1. Value Conversion

For some Data Points it's helpful to normalized their numerical value before applying the scoring function, but this is an optional step.

Examples:

• Convert twitter_account_age from a timestamp to the number of years the account has.

• Normalize base_out_transactions with a sqrt function to reduce the impact of large values, making the scoring system more balanced and fair, and ensuring big contributors don’t completely overpower smaller ones. This means that your first contributions matter more than later ones.

• Invert farcaster_social_capital_rank value, so that the #1 ranked user has a higher value (and more points) than the last ranked user.

2. Signal Strength

Defines how strongly a given data point proves that the user is a real builder, and can have 3 possible values: weak, medium, strong.

Examples:

• Winning a ETHGlobal hackathon is a strong signal that someone is a real builder.

• Simply having a GitHub account is a weak signal that someone is a real builder.

3. Max Score

Defines the maximum amount of points each Data Point can contribute to the overall Builder Score. We use the signal strength to help define the max score of each Data Point:

• strong (up to 40 points)

• medium (up to 20 points)

• weak ( to 8 points)

4. Multiplier

In the Builder Score we use a multiplier to automatically convert the numerical value of a Data Point into a score, measured in "points".

The multiplier is needed in order to standardize very different scales of Data Point values.

Summary

The Builder Score represents 3 core decisions:

1. What Data Points are relevant to assess the reputation of a builder.

2. How strongly does each Data Point signal that the user is a real builder.

3. What should be the multiplier to convert each Data Point value into Builder Score points.

The final Builder Score is the sum of all the points.

Builder Score doesn’t have a maximum cap, so it’s likely to increase over time, as we add more integrations and possible credentials to the protocol.

A protocol primitive that aggregates onchain activity like transactions, balances, and contract deployments.

We're currently supporting activity from Arbitrum, Base, BNB Chain, Celo, Ethereum, and Optimism.

Events to track how reputation changes over time, giving users better insights into their progress. Think of it like Etherscan for the Builder Score: users will be able to see not just their current reputation state, but the complete history of how they got there.

Every change to reputation data is recorded as an Event with its old value, new value, and timestamp.

Key Attributes:

• Represents a chronological log of changes to each Data Point:

• Each event stores: old value, new value, timestamp

• An Event does not include scoring information but is used to calculate scores when processed.

Event vs Data Point

• A Data Point shows the current state (e.g., total commits), and the Event tracks the history of changes leading to the current state.

• Just like Etherscan, where you see both the current token balance (state) and the transactions (events) that built up to it.