Huma Protocol

Decentralized signal portfolio(DSP)

The Decentralized Signal Portfolio (DSP) is an open platform that enables access to high-quality signals about a borrower's income, assets, and liabilities. These signals are collected through Signal Adapters hosted on the DSP, which gather data from a variety of on-chain and off-chain sources. Any developer can contribute to the platform by adding a new Signal Adapter for a specific data source. By adding and improving these signals, we can not only improve the quality of evaluations made by Evaluation Agents but also provide a valuable data source for reuse by the broader ecosystem.

Types of Signals

Income-related signals help understand the amount, frequency, and other objective quantities that describe the income associated with a wallet. This can include information about predicted future income from that source as well.
Asset-related signals help understand the quality and quantity of the borrower's assets.
Liabilities are signals about borrowers' payment obligations from their assets and future income.
There is a wide range of sources that a Signal Adapter can be developed. Examples include;
  • On-chain sources
    • Direct payments from treasuries, i.e., Gnosis SAFE’s, Circle Business Account
    • Payments/invoices like Request Network, Utopia Labs, Coinshift, Superfluid
    • Positions in lending pools
    • Yield farming
    • Staking, miner, and validator income
    • Gaming income
    • NFT royalties
  • Off-chain
    • Balances, transactions, and revenue like Plaid, Teller, Stripe, Quickbooks, Recurly
    • Invoices like Bill, Stripe, PayPal, Invoice2Go, Square, Zoho
    • Income data aggregates like Pinwheel, Finicity, Argyle
    • Sales data like Shopify, Amazon
    • Credit/debt data aggregates like Experian API

Example of a Signal Adapter

See the Eth Transactions Adapter for a working example.

Contributing new Signal Adapter

All signal adapter codes are under the example folder.

Adding signal definition

Add a new signal definition class to list all the signals supported by the new adapter.
class WalletEthTransactionsSignals(Model):
total_transactions: int
total_sent: int
total_received: int
wallet_teneur_in_days: int
total_income_90days: float
total_transactions_90days: int

Adding signal adapter logic

Add an Adapter class with code to actually fetch data from external sources and compute any derived signals:
An example:
class WalletEthTransactionsAdapter(AdapterBase):
name: ClassVar[str] = "wallet_eth_txns"
required_inputs: ClassVar[List[str]] = ["wallet_address", "network"]
signals: ClassVar[List[str]] = WalletEthTransactionsSignals.__fields__.keys()
def fetch(
self, input_a: str, input_b: str, input_c: str
) -> WalletEthTransactionsSignals:
  • Secret management
    • For now, secrets should be included in dotenv and loaded thru settings when DSP service is initialized.
    • In the future, we are going to manage them with KMS.
  • Name
    • Each Signal Adapter should have a unique name.
    • The Signal Adapter's name is used as the namespace for signals.
    • For example, a signal's full name looks like signal_adapter_name.signal_name so we can avoid name conflict.
  • Required Inputs
    • These are the inputs a signal adapter required to fetch and compute signals.
    • It's the caller's responsibility to provide these inputs. In most cases, the caller will be the Huma Evaluation Agent
  • the fetch method
    • The unified interface to receive inputs and return computed signals.


Please make sure to include extensive tests under tests.
  • We use pytest for test framework.
  • Make sure to use pytest-describe to organize tests. Please provide the necessary fixtures to properly test the new adapter end-to-end.

Life Cycle of a new Signal Adapter

  1. 1.
    Implement the Signal Adapter according to the provided interface, and submit a pull request for review by Huma DAO.
  2. 2.
    If your Signal Adapter is accepted, it will be deployed on the DSP with the appropriate open-source license.
  3. 3.
    All accepted Signal Adapters will be listed and available for use by Evaluation Agents (EAs).
  4. 4.
    Performance and usage statistics for Signal Adapters will be regularly collected and shared as metadata. This information will be valuable to EA developers in choosing the most robust Signal Adapters, and will also be used to calculate rewards for contributors.
  5. 5.
    Each Signal Adapter must be maintained by its original developer, Huma DAO, or the community. The maintainer will receive rewards but is also responsible for meeting service level agreements, implementing new features, and addressing bug fixes for the Signal Adapter.

(Coming Soon) Developer Participation and Rewards

We invite developers to contribute to the initial development and ongoing maintenance of Signal Adapters on the DSP platform. As a way to kickstart development, Huma offers bounty programs and a portion of the protocol revenue will be allocated to reward Signal Adapter developers and maintainers. The Huma DAO will review all contributions and determine how to distribute the reward pool among different contributors. Join us and be a part of building the future of decentralized finance!