Temperature Check: Building a Talent Hub for Cosmos


It’s widely recognized in the Cosmos Ecosystem that there are certain coordination challenges. These are inherently linked to the decentralized nature of the system, which is a feature, not a flaw. However, these issues should be addressed to alleviate the problems they create, potentially hindering adoption. One such challenge concerns the absence of a centralized entity to effectively guide and unite talent within the ecosystem.


To further analyse the situation, we also found that there was an enormous reliance on trust assumptions regarding credibility of actors. More often than not, subjective judgement prevails instead of quantitative and qualitative analysis. If left unaddressed, this issue will result in ‘cartelization’ and reputation systems that prioritize connections over merit-based and accountable approaches as the system scales.

Secondly, we have identified an overemphasis on development, which unintentionally discourages the involvement of other skill sets, such as marketing, business development, and traditional finance. We have also observed a significant growth in the developer cohort, leading to increased specialization. To prevent fragmentation, a clear categorization of sub-specialties is required.

Additionally, the absence of accountability threatens the long-term sustainability of the workforce and its capacity to attract top talent, favoring historical contributors with potentially outdated merit and past reputations, some of whom have not contributed for an extended period or have been involved in public controversies.

Beyond these obstacles, we believe there is an even more significant challenge to overcome: the difficulty in recruiting independently. We have determined that this is a result of the multiple tasks assigned to the InterChain Foundation (ICF), which has historically coordinated recruitment efforts. This system faces communication overhead as it scales, and we recommend a collaborative public-good initiative between the Hub and the ICF to address this issue. This system should offer a trust-less platform that enables confidential communication between recruiters and candidates, with a spam-protected system that can scale effectively.

To summarize, here are he problems we think should be addressed:

  • the lack of a one-stop-shop to list all talents in Cosmos.
  • the reliance on a fragmented set of people (the historical leaders).
  • a subjective reputation based system for recruitment.
  • the absence of non-developer talent recognition in the ecosystem.
  • the need to categorize developer cohorts by their specialties.
  • an unworthy system favoring historical actors without accountability.
  • the difficulty to scale communications between recruiters and candidates.


Before going any further, we would like to emphasize that this is just the result of our internal brainstorming within the PRO Delegators’ team. We are eager to gather community feedback and improve on our ideas.

To present a detailed plan for the project, we suggest proceeding in a series of sequential steps:

  1. Community debate: First we would like to query the general sentiment see if we are in the right direction. We provide our initial design right below and we welcome community feedback on improvements and potential technical challenges this could pose for the specifications & development phases.

  2. Specifications: We think this program should follow a regular process, which counts for a thorough governance debate right here in the forum, followed by a specification phase similar to the CHIPs process. The goal is to clearly define the technicalities to define an estimated cost of operation to build it. This specification phase is essential to define Key Performance Indicators (KPIs).

  3. Funding: Due to the public good nature that extends way beyond the Cosmos Hub into the entire Cosmos Ecosystem, this should be a joint-funded program which financial details should be debated between the ICF’s @crainbf and @Youssef from the AADAO.

  4. Tokenomics: To our humble opinion, this system does not need a separate token. The community is invited to share their feedback on this if they have relevant alternate options. The close alignment to the Hub’s neutrality is perfectly suited for this public-good task. Our initial design has not accounted for a specific governance module inside the chain itself, therefore depending from the Hub’s governance. Of course this could change depending on community feedback.

  5. Building: A competent team of developers should be tasked to scaffold the chain itself using the Cosmos SDK and tailor the specific modules required for the operations defined in the specification phase. A second team should work in parallel to build the application front-end itself. It seems evident that the two teams should have direct communication between the whole process but should have separate KPIs (Key Performance Indicators) to release their respective funding. This further improve resilience and isolate the risks to avoid past mistakes.

  6. Infrastructure: The core idea resides on a trustless execution, therefore the Hub should be the provider chain for the security, this seems like a no-brainer to us. Due to the public-good nature of this system, it should consider a Partial-Set-Security (PSS) deployment and the “top-N” model seems the most appropriate to limit the infrastructure costs. The minimum 50% top-N should be more than enough considering the low profitability margin of public-goods operations. We also propose that gas fees collected should be equally distributed to the participating validators, not only the bloc proposers to better balance the revenue distribution.


To clarify our proposal, we have outlined our thoughts on the desired architecture of the chain, including the modules and sub-categories we believe should be considered. We remain open to community feedback on this matter.

The core features we envision to define the specifications:

  • ONE-STOP-SHOP (HR meets talents & developers in the Cosmos)
  • FOSTER BUSINESS IN THE AEZ (Removes all the friction, both from the recruiter and the recruitee sides, emoving trust and adding on-chain accountability)
  • AUTHENTIFIED ACCOUNT OWNERSHIP (registering as a user on the platform requires a one-time stATOM deposit, refunded after 21d on account’s closure. Users can connect to their web2 accounts to prove ownership on-chain)
  • EASY INTEGRATION WITH WEB2 TRUSTED SOURCES (bring your achievements, badges etc… on-chain, validators connect via API & websocket to verify authenticity)
  • PROVABLE USER CONTRIBUTIONS (validators commit stake and the block producer will be slashed if relevant misbehave is brought to governance)
  • SPAM-FREE MESSAGING SERVICE (Each account can define a minimum fee to receive messages, natively preventing spam)
  • AUCTION SYSTEM FOR TALENT QUERY & CONTACT (the recruiter defines its criterias, the Dapp calculates the relative cost to reach those users. The cost is transparent and trustless. Once deposited, the app casts the relevant transactions containing the encrypted message sent to the users. Opening the message sends a proof to the recruiter)
  • DENTRALIZED PAYCHECK SERVICE (allowing KPIs release & vested payments in any whitelisted token thanks to the fee abstraction module)

Functionality Overview:

For those who are less familiar with the Cosmos SDK and blockchain architecture we want to share a high-level overview of the application that we envision from the users’ and validators prospective.

  • Candidates: A unified platform for job seekers to submit applications to a transparent talent ledger. To proceed, create an account and make a sizable minimum deposit to prevent spam and misconduct. We suggest using stATOM for compounding staking rewards over time, which will be returned to you (x) days after closing your account, provided you haven’t been flagged on-chain. Following deposit, link your accounts on trusted web2 platforms, such as GitHub, Node-Guadians, LinkedIn, etc. You can choose which data you want to be attested on-chain, while your public profiles remain off-chain. Misconduct or duplicate claims will result in deposit slashing on both accounts. Additionally, select keywords from a list to describe your skills and set hourly salary, availability, notification preferences, and the fee for contacting you.

  • Recruiters & HR managers: They also need to set an account and deposit a refundable fee to discourage spam and inappropriate behavior. To start a recruitment campaign, users define candidate criteria, and the app identifies eligible users along with their connection fees (with higher fees for highly skilled users, attracting serious recruiters). After choosing candidates and campaign duration, the app calculates the total cost and directs users to send the escrow contract amount on the bank module for later execution. Eligible users receive a private email notification to connect, prompting them to accept or reject the connection via the app. Any answer posted on-chain releases the full fee from escrow to the user’s account. If no response is given by the campaign end, the fee is returned to the recruiter. If approved on-chain, a secure, on-chain, end-to-end encrypted message channel is established between the candidate and recruiter, open for the campaign duration and closing automatically if not extended by both parties. Each side can also cast a transaction to close the channel irrevocably.

  • Validators: Confidential information is stored in a web2 application database with a restricted API, accessible only to active validators. These validators collaborate to verify and submit on-chain attestations concerning the validity of users’ achievements, while keeping web2 profiles private. Over time, validators can broaden the scope of private data attestations, providing additional filtering options for recruiters.

  • Attestors: Additionally, reputable developers and talented individuals can participate in decentralized KPI reviews for open-source projects, pledging their deposit and reputation. Their votes, cast on-chain, determine KPI-based payments, creating a decentralized market for responsible and credible reviewers with verifiable evidence of their skills and accomplishments.


Question: why not simply a website?
Answer: as we highlighted in our analysis, there is a huge reliance on trust assumptions and a lack of accountability today. Having on-chain attestation is a perfect solution to these problems. The verification is performed by (x) independent validators risking ATOM slashing if they misbehave. Another crucial problem is the reliance on a few individuals to connect projects and developers with a communication overhead issue preventing scaling. A blockchain marketplace with proper financial incentive and spam deterring features offer near infinite scaling with no third party reliance. Finally, as the system involves collateral deposits and payment incentives, a blockchain offers unparalleled security and transparency to execute these critical pieces.

Question: private data and blockchain, isn’t that conflicting ?
Answer: Some data has to be publicly viewable to remove trust assumptions and false claims. Nonetheless, anonymity preservation is key to a worthy on-chain system. To prevent user identification recruiters will have limited numbers of searches to the website. We also want to ensure that the engine will prevent from performing “narrow searches” only resulting in a few candidates, which would allow them to be identified more easily.

Question: how can this system accrue value ?
Answer: it is not designed to be profitable, we designed it with a public-good vision (community feedback can demonstrate disagreement and propose changes to the tokenomics). We expected to charge a cost-based gas fee to cover for validator execution. As we expect to run on a minimal setup, we estimate that overall gas cost should still be affordable for users (few cents).

Question: how does it benefit ATOM holders ?
Answer: firstly, some supply will be removed from circulation to provide collateral and prevent spam. We also propose to use @Stride stATOM to increase the overall security with this capital. A more indirect effect is that the overall constraint the current system poses to the general ecosystem growth shall benefit to everyone’s experience. Less friction in the recruitment system and a more equitable access the workforce participation can only benefit every cosmonaut. Finally, this system is designed to run autonomously and scale, ultimately doing a better job than creating a specific DAO with individuals and monthly salaries to pay for their contributions.

Closing thoughts:

To wrap up, we would like to express our gratitude to everyone taking part in this conversation. We welcome all viewpoints and invite you to share them here. Kindly remember that a constructive dialogue hinges on respectful behavior among participants. Please make an effort to maintain politeness and open-mindedness towards everyone’s contributions.

Thank you for taking the time to read this, and we look forward to collaborating on bringing this concept to fruition. This journey may be long, but we are honored to be the ones taking the first step today.


I like the concept !

What would be the main challenge to implement it and is there any downside in your opinion?

Also, do we have a way to quantify or “show” what’s the current/potential demand in terms or applicants, jobs offering… etc within the AEZ ? Showing data could help to decide.

I like the neutral and non profitable aspect of this proposal. Just a tool, not another punzi. Looking forward to the discussion

Thank you Govmos for you dedication to the Cosmos community :slightly_smiling_face:


We think the ecosystem as whole should approach this topic as a necessary public-good funding. The key argument we shared relates to the fact that there will be an inevitable bottleneck in the future if this situation is not addressed preemptively. We are currently relying on foundations and DAOs which won’t be able to follow the demand as it scales. Moreover, creating a decentralized platform to take over the charge will require extensive work to be designed, specified, built, tested, and lastly implemented.

Due to the public nature of the business and its relatively low profit margin to operate correctly, we identified this as a perfect match for a joint funding from the two sources currently operating this human ressource coordination, namely the AADAO and the ICF.

As we previously described, building public infrastructure takes time, more than building in a centralized manner. This is why we think it is important to kickstart the first steps long before the actual bottleneck shows up. To this day, the plan is initiate community discussions, ideation and brainstorming. The goal should be to collectively declare our willingness to build such infrastructure, define the key features and components needed to achieve them. The next stage will be more technical as it involves defining clear specifications and cost estimations.

To answer your question more directly, the biggest challenge lies ahead of the specification and funding phases. We’re not yet there as this post only clears the path for community discussions. Regarding the downside, we only see the community spending required to fund the actual building. The community will have to balance the necessity-cost ratio.

Bringing a talent portal onchain is definitely an interesting usecase. Onchain attestations could solve some of the assumptions and trust involved with recruitment today - but I’m still unsure how we can utilize this for qualitative evaluations/data.

Regardless, agree with @Govmos that such a project will probably (esp at this stage) be a public goods type project. We will probably need a few trailblazers to innovate, experiment and then quash traditional recruitment portals.

If any team is looking to build on this idea, do give us at @ATOMAcceleratorDAO a shout!


This is indeed the tricky part to understand so you are correct to point it out, this clearly requires deeper explanations. Let us review step by step to answer your question properly:

  1. The main challenge in the design is to maintain privacy of user’s whilst bringing authentication to the data. The best solution we could find was to hold the database in a classic web2 server with access limited to active validators while the frontend is open-sourced. This is how we achieve the trust-minimization privacy preserving while having a decentralized execution made by a cohort of validators which risk severe reputation backlash if they ever break the privacy commitment. Moreover we clearly imagined a system where social consensus will slash via the Hub governance if someone ever does this.

  2. Once we have that private database, its important to understand how the data flows. On this server, the data is processed by the open-sourced frontend, therefore only the users with credentials are interacting via the app can write on this database (and also delete information when they want out). On their side the validators are only allowed to read.

  3. We assume that users of this system should have enough security & privacy guarantees to add as much data as possible regarding their profile. Let’s imagine a developer, the first thing I would do would be to connect my github account, and reference all the repos I have been contributing on. The app should be able to collect all that data from github if you authorized it.

  4. Now that we have a vast amount of data linked to profiles (provable contributions), we can talk about the search engine and the qualitative aspect you asked about. Let’s assume a recruiter wants to hire someone with the highest level of competence in IBC middleware development. Now this is purely hypothetical as the specification phase hasn’t yet happened but let’s imagine what that person would input in the search engine to find the best candidates:
    Criteria1: User must have 4+ years of provable developer experience.
    Criteria2: User must be available now for a 6 months part-time job
    Critera3: User must have contributed at least 10 commits to a repo with “IBC middleware” keyword included AND/OR user need to have passed the IBC middleware spectialty test in NodeGuardian AND/OR user need to have passed the level3 test from the ICA on IBC middleware.
    Criteria4: User need to have GoLang certification.
    Criteria4: User base full-time salary must be lower than 120k/y
    Criteria5: User must speak english

With this system, recruiters can benefit from guaranteed results, with the option to contact users who meet their criteria if they agree to pay the required minimum fee. Moreover, the amount of eligible qualitative data can easily scale, as the system uses API/websocket to collect the data on reputable sources, it is up to the community to add new sources beyond github. We see this as a huge opportunity to leverage the InterChain Academy to create more and more certified qualifications and directly integrate them. This system extends beyond just providing qualified candidates, as it has the potential to serve as a central hub for all sort of contributors: those looking for work, recruiters, but also project initiators, marketing experts, and more. This system can scale as the workforce expands.

A valuable addition could be an analytics dashboard that identifies trends, gaps, and more. This could help address coordination issues, enabling people to find each other and collaborate more effectively. The integrated messaging system facilitates communication between parties, eliminating the need for complex networks of contacts that can introduce subjective filtering processes.

We hope this answers your question!


Welcome to apply for the QF grant that is dedicated to support teams and public infra like yourself!
You could find on DoraHacks website, or feel free to reach out to me on TG: chris_dora
would love to learn more about it.