ARCx
Search…
Infrastructure overview

Score creation

The DeFi Credit Score is processed using custom data pipelines that pull on-chain data sources. Our pipelines are flexible, which allows us to increase the scope of data included in the Credit Score as required. The decision to use custom ETL pipelines allows our score designers to experiment with complex score logic with minimal effort (compared to endless SQL queries, for instance). Having a large, accessible and tailored dataset enables quick adjustments and in-depth analyses.

Score publishing

The DeFi Credit Scores (and other on-chain scores) are combined into Merkle Trees, with its Merkle root (i.e. the root of all combined trees) being published on every blockchain we support. This process occurs every Epoch, which is currently set at a 24 hour window. To save on resources and processing time, subsets of scores are combined into smaller Merkle Trees, so as to be created in parallel. Then, the roots of each tree are combined into another Merkle Tree, and the process is repeated. The final Merkle Tree thus contains all the Credit Scores and are verifiable against the final Merkle Tree’s root deployed on each respective blockchain. All roots on each blockchain are equivalent at each epoch. This also means Credit Scores are chain agnostic (i.e. same score on each blockchain).
Before a new root becomes active on the blockchain, it must first spend 1 epoch on the *SapphirePassportScores* contract as the “upcoming Merkle root”. This intermediary step of having a public “upcoming root” provides an additional layer of security and transparency, allowing for anyone to externally validate both the “current root” and the “upcoming root”. When a new root is thus published, the “upcoming root” becomes the “current root”, and the new root takes its turn as the “upcoming root”. This also allows for integrity and security checks for an entire epoch before any root goes live. This entire process provides many failsafes while also providing a gas-efficient and cryptographically secure way to publish scores on-chain.

Score verification

Applications wanting to use a score on-chain will need to fetch its proof, which can be found via our publicly accessible REST API. Third parties can verify any score on-chain by passing its proof to the verify(...) function on our SapphirePassportScores contract.

Comparison table

Alternative solutions to the problems described above exist, but these suffer from a variety of challenges as described below:
Option
Pros
Cons
Merkle Root Publishing
  • No external dependency
  • Gas efficient (single Merkle Root)
  • Low data integrity risk
  • Highly flexible
  • Transparent
  • Slower score updates
  • Large infrastructure to build
Publish on-chain through existing oracle service
  • No need to build extra infrastructure
  • Faster score updates
  • Gas intensive
  • High data integrity risk
  • Not as transparent
  • Not flexible
  • External dependency
Build competing oracle service
  • No external dependency
  • Faster score updates
  • Gas intensive
  • High data integrity risk
  • Not as transparent
  • Immense infrastructure to build