Skip to main content
Qualifying access to products is a way to ensure that eligible individuals and entities are able to access appropriate products or services. This can be done for a variety of reasons, such as to protect the interests of the provider, to ensure that the product is being used by the intended audience, or to mitigate risk.

​
Why Qualify Access?

Risk Mitigation

Reduce exposure to defaults and bad actors by limiting access to creditworthy participants

Better Terms

Offer improved rates or conditions to users who demonstrate financial responsibility

Protect LPs

Safeguard liquidity providers by ensuring borrowers meet minimum creditworthiness standards

Regulatory Compliance

Meet compliance requirements by implementing risk-based access controls

​
Example: Lending Pool Access

A lending pool may only be accessed by accounts with an “Excellent” credit score. This is because the provider of the lending pool may want to minimize the risk of default on loans, and therefore only wants to provide loans to individuals or entities that have a proven track record of responsibly managing credit. 
const { score, range } = await getCredScore(userAddress);

if (range === 'excellent') {
  // Grant access to premium lending pool
  await grantPoolAccess(userAddress, 'premium-pool');
} else if (range === 'very_good' || range === 'good') {
  // Grant access to standard pool with higher collateral requirements
  await grantPoolAccess(userAddress, 'standard-pool');
} else {
  // Require additional collateral or deny access
  showMessage('Credit score too low for this pool');
}

​
Example: Yield Aggregation Tiers

A yield aggregation protocol may only offer specific pools to accounts with credit scores over 800. This is because the provider may want to ensure that only the most financially stable individuals or entities are able to access higher-risk, higher-reward pools. 
const { score } = await getCredScore(userAddress);

const availablePools = [];

// Base pools available to everyone
availablePools.push('stable-yield-pool');

if (score >= 750) {
  // Medium-risk pools for good credit
  availablePools.push('balanced-yield-pool');
}

if (score >= 840) {
  // Higher-yield pools for very good credit
  availablePools.push('growth-yield-pool');
}

if (score >= 920) {
  // Premium pools for excellent credit
  availablePools.push('premium-yield-pool');
  availablePools.push('leveraged-strategies-pool');
}

return availablePools;

​
Implementation Patterns

​
Gate by Score Range

Use the range field for simple tier-based access: 
async function checkAccess(address) {
  const response = await fetch(
    `https://api.credprotocol.com/api/v2/score/address/${address}`,
    { headers: { 'Authorization': `Bearer ${API_KEY}` } }
  );

  const { range } = await response.json();

  switch (range) {
    case 'excellent':
      return { tier: 'premium', collateralRatio: 1.1 };
    case 'very_good':
      return { tier: 'standard', collateralRatio: 1.25 };
    case 'good':
      return { tier: 'basic', collateralRatio: 1.5 };
    default:
      return { tier: 'restricted', collateralRatio: 2.0 };
  }
}

​
Gate by Minimum Score

Use the numeric score for precise thresholds: 
const MIN_SCORE_FOR_ACCESS = 750;

async function canAccessProduct(address) {
  const response = await fetch(
    `https://api.credprotocol.com/api/v2/score/address/${address}`,
    { headers: { 'Authorization': `Bearer ${API_KEY}` } }
  );

  const { score } = await response.json();
  return score >= MIN_SCORE_FOR_ACCESS;
}

​
On-Chain Integration

For smart contract integration, you can verify scores off-chain and pass the result on-chain, or use an oracle pattern: 
// Simplified example - verify score off-chain, gate on-chain
contract CreditGatedPool {
    mapping(address => bool) public approvedBorrowers;

    function approveBorrower(address borrower) external onlyOracle {
        approvedBorrowers[borrower] = true;
    }

    function borrow(uint256 amount) external {
        require(approvedBorrowers[msg.sender], "Not approved");
        // ... borrowing logic
    }
}

​
Best Practices

Credit scores are cached for 5 minutes. For access control decisions, consider caching the approval status rather than re-checking on every interaction.
When denying access, tell users why and what score they need. This transparency helps users understand the requirements and potentially improve their creditworthiness.
Rather than binary access control, consider tiered access where lower scores get higher collateral requirements or lower limits, rather than complete denial.
Test your access control logic using sandbox endpoints before deploying to production. Sandbox returns deterministic scores based on address, making testing predictable.

Get Credit Score

API reference for fetching credit scores

Score Ranges

Understanding score classifications