Onchain credit without a bureau file
A public trail is not a credit file, and an address is not a person. Separate the observation from the rule that turns it into a limit.
Sample note, written to show the format. The bands and the rule below are illustrative. They are not a score and not anyone’s current policy.
Credit on a public chain does not come with a bureau file. What you have is a trail: addresses, positions, liquidations, repayments, and the gaps between them. A data note is a decision about which parts of that trail are allowed to count.
The temptation is to treat an address like a person. It is not. One person has many addresses. One address has many people, if it is a treasury, an exchange or a bot. Any feature built on “this address” has to say which of those it assumes. For a consumer product the honest label is: this describes the address you connected, not you.
What usually gets counted
The families below show up again and again. The bands are a teaching grid, not a fitted model. A real book would replace them with its own loss history, which this sample does not have and will not invent.
| Family | Example of a raw input | Illustrative band | How it misleads |
|---|---|---|---|
| Age | First transaction of the address | Under 30 days is thin | Old dust is not a history of borrowing |
| Repayment | Loans closed without a liquidation | Most close, or they do not | One protocol’s flag is not another’s |
| Proximity | Collateral ratio at a snapshot | Near the line, or not | Stale within a block |
| Concentration | Share of collateral in one asset | Single asset, or mixed | Mixed assets can still move together |
| Behaviour | Bridges and rapid in-and-out | Stable, or churny | Churn can be a market maker |
Observation, then a rule
Separate the observation from the judgment. An observation is “this address was liquidated twice in ninety days on the protocols in the sample”. A judgment is “therefore the next loan should be smaller”. The first can be shown to a user and to a risk committee. The second is a policy, and it should sit in a table someone can edit, not in a weight nobody can read.
An illustrative rule, round on purpose:
if liquidations_90d >= 2 then max_ltv = base_ltv - 15 points
if address_age_days < 30 then max_ltv = min(max_ltv, base_ltv - 20 points)
else max_ltv = base_ltvFifteen and twenty are not a result. They are placeholders so the shape of the rule is easy to read. Publishing a fake loss curve would be worse than publishing the rule with the numbers marked as made up.
Coverage is the quiet problem. A feature that exists for one lending protocol and not the three others will look precise and be biased toward whichever chain was indexed first. A breakdown should say which protocols are in the sample, which chains, and the date of the pull. Without that box it is a mood.
What belongs on one page: the feature, the raw value, the band, the protocols included, and the rule that turns the band into a limit. Five columns. If a column is missing, the note is not finished, however nice the chart.