Skip to main content
Every principal is underwritten from its first day on Tythe, using its on-chain history alone. Everything it does afterwards, on Tythe and, with consent, in its bank accounts, sharpens the picture. This page explains the sources, the model, the outputs, and the process for disputing a result.

​
Three sources

Each feature the model uses carries a provenance weight: activity on Tythe outranks bank data, which outranks inferred on-chain activity. The model uses both the value and its provenance.

​
Graceful degradation

A principal is ratable on the first source alone. The second and third sources tighten the confidence band and, over time, raise the Credit Rating and the Credit Limit. A principal that never connects a bank account and never borrows is still rated, from on-chain history and whatever it does on Tythe.

​
The model

The Entity Underwriting Engine is a constrained machine-learning model. Three things make it constrained.
  • Structure. Established credit science is encoded as feature design and monotonic constraints, so the model cannot contradict it. Greater revenue stability can never lower a Rating. Higher counterparty concentration can never raise one. A longer clean repayment history can never hurt one.
  • Training and calibration data. The model is trained on public on-chain data at scale, using measurable proxies for financial durability (activity survival, cashflow continuity, drawdown recovery, counterparty churn), and calibrated on the public outcomes of undercollateralised on-chain credit protocols. Credit Limits are set conservatively at launch by calibration.
  • Continuous learning and versioning. Every underwriting decision and every Loan outcome on Tythe is logged as a labelled example. The model is retrained on a schedule. Every version is recorded in the attestation that carries your Rating, so a version can be retired by governance and any decision traced to the version and inputs that produced it.
The model produces reason codes for every rating. It never uses protected characteristics.

​
Outputs and what they drive

Your Credit Limit can fall on re-rating. Existing Loans keep their terms. New draws shrink to the new available limit, and your agents’ credit shares shrink with it.

​
Cadence and triggers

Ratings are refreshed weekly and on triggers: a large balance change, a missed capture, a dispute, a newly connected source, a suspension. Each refresh produces a new attestation.

​
Disputes

Your console shows the reason codes behind every rating.
1

Read the reason codes

Each rating lists the factors that most affected it and the direction of their effect.
2

Raise a dispute

Submit the dispute from the console with the factor you contest and any supporting information.
3

Review

Tythe reviews the inputs and the model’s treatment of them. Where an input was wrong or the model mis-handled it, the correction lands in your next attestation.
Ratings are assessments, not negotiations. A dispute can correct an error; it cannot change a rating that reflects the data correctly.

​
What is never used

Protected characteristics. Data you have not consented to. Bank data outside its consented scope. Data from other principals’ bank accounts.
For developers. A principal’s current Rating and Credit Limit are readable on-chain from the attestation registry, with the model version and expiry. See the contract reference.

Agent underwriting

How each agent earns its effective scope inside the ceiling you set.

Borrow

How the Credit Rating and the Credit Limit become Loans.