Proposal type
Other
Affected scope (files/folders/chains)
https://github.com/Chain-Love/chain-love/wiki/Style-Guide
Motivation / problem statement
We have encountered situations where the provider name is not clearly the same thing as the product/project name.
Examples include:
prb-test
venus-wallet
open-source projects maintained by an individual developer
projects associated with a protocol/foundation but maintained by a separate team
products that are repositories rather than commercial companies
This creates uncertainty about whether the provider should represent:
the project name,
the GitHub organization,
the individual maintainer,
the foundation/protocol,
or the organization actually responsible for maintaining the software.
This directly conflicts with the conceptual separation of:
provider → offer → listing
because the database needs to know who the provider actually is, rather than simply repeating the product name.
Proposed rule
Define a standard method for determining the provider when an offer is:
maintained by an individual;
maintained by a GitHub organization;
developed by a foundation;
part of a protocol ecosystem;
forked from another project;
or operated by a separate team from the protocol/project it serves.
Suggested decision hierarchy
For example:
Commercial organization clearly owns/operates the product → organization is provider.
Foundation/team clearly maintains the project → foundation/team is provider.
GitHub organization is the identifiable accountable maintainer → GitHub organization may be provider.
Individual developer is clearly the accountable maintainer → define whether the individual can be represented as provider.
Protocol/network itself is merely the ecosystem in which the tool operates → do not automatically use the protocol as provider.
Evidence requirement
Define what evidence is sufficient:
official website;
official documentation;
GitHub organization/repository;
maintainer statement;
foundation documentation.
Why this is a good DBIP
This is not just about PRB Test. It potentially affects SDKs, services, wallets, developer tools, infrastructure and other open-source offers.
Detailed proposal
If proposing a new/changed category (table):
- Category name:
- Purpose and scope:
- Primary use cases:
- Example entities/providers to include:
- Does this category applies to specific chains? If so, list them:
- Required columns (list):
- Optional columns (list):
If proposing column change(s):
- Category/table (rpc | wallet | explorer | indexing | bridge | analytic | devTool | oracle):
- Column name:
- Change type (add | remove | modify):
- New/updated definition:
- Value type and allowed values (string | number | boolean | JSON array | JSON object | NULL | enum:):
- Examples (concise):
- Notes (constraints, normalization guidance (check wiki for references)):
Contact (optional)
No response
Rewards address (optional) 0xbebb8c6309b58218b62138ed88669658ebe4804a ERC20
No response
Proposal type
Other
Affected scope (files/folders/chains)
https://github.com/Chain-Love/chain-love/wiki/Style-Guide
Motivation / problem statement
We have encountered situations where the provider name is not clearly the same thing as the product/project name.
Examples include:
prb-test
venus-wallet
open-source projects maintained by an individual developer
projects associated with a protocol/foundation but maintained by a separate team
products that are repositories rather than commercial companies
This creates uncertainty about whether the provider should represent:
the project name,
the GitHub organization,
the individual maintainer,
the foundation/protocol,
or the organization actually responsible for maintaining the software.
This directly conflicts with the conceptual separation of:
provider → offer → listing
because the database needs to know who the provider actually is, rather than simply repeating the product name.
Proposed rule
Define a standard method for determining the provider when an offer is:
maintained by an individual;
maintained by a GitHub organization;
developed by a foundation;
part of a protocol ecosystem;
forked from another project;
or operated by a separate team from the protocol/project it serves.
Suggested decision hierarchy
For example:
Commercial organization clearly owns/operates the product → organization is provider.
Foundation/team clearly maintains the project → foundation/team is provider.
GitHub organization is the identifiable accountable maintainer → GitHub organization may be provider.
Individual developer is clearly the accountable maintainer → define whether the individual can be represented as provider.
Protocol/network itself is merely the ecosystem in which the tool operates → do not automatically use the protocol as provider.
Evidence requirement
Define what evidence is sufficient:
official website;
official documentation;
GitHub organization/repository;
maintainer statement;
foundation documentation.
Why this is a good DBIP
This is not just about PRB Test. It potentially affects SDKs, services, wallets, developer tools, infrastructure and other open-source offers.
Detailed proposal
If proposing a new/changed category (table):
If proposing column change(s):
Contact (optional)
No response
Rewards address (optional) 0xbebb8c6309b58218b62138ed88669658ebe4804a ERC20
No response