TRUFA Scoring

Source of truth: DOBVALIDATOR/docs/TRUFA.md for the methodology and DOBVALIDATOR/distribution-contracts/contracts/DOBValidator.sol for the on-chain struct.

TRUFA stands for Trustless Revenue Utility & Flow Automation. It is the methodology DobValidator uses to evaluate how autonomous, verifiable, and revenue-generating a tokenisable real-world asset (typically a DePIN device or piece of infrastructure) is.

The acronym is not a per-letter mapping to scoring dimensions. The score itself is a 0–100 composite of four independent dimensions described below.

TRUFA scale (0–100)

From the methodology doc:

Score	Meaning
0	Fully manual operation, no verifiability, black-box cash flow.
25	Basic revenue documentation, some historical data, no live metrics.
50	Partially automated device with API exposure, still human-managed.
75	Fully connected device with live metrics and automated revenue.
100	Autonomous, decentralised machine + on-chain revenue + fallback logic.

Scoring dimensions (on-chain)

The on-chain struct in DOBValidator.sol:

struct TrufaScores {
    uint32 technicalFeasibility;     // 0..100
    uint32 regulatoryCompliance;     // 0..100
    uint32 financialViability;       // 0..100
    uint32 environmentImpact;        // 0..100  (note: environmentImpact, not environmental)
    uint32 overallTrufaScore;        // 0..100
}

Each dimension is validated <=100 on-chain in setProjectApproved.

Technical feasibility

Is the device technically sound and capable of operating as described? Validators look at device specs vs. claimed output, installation quality, technology maturity, and supplied technical documentation.

Regulatory compliance

Is the asset operating legally in its jurisdiction? Permits, licenses, safety certifications, environmental permits, and tax/reporting structure.

Financial viability

Are the asset's revenue claims realistic? Revenue model, cost structure, payback period, market conditions, and supporting financial documentation.

Environment impact

Net environmental footprint — carbon, resource efficiency, waste handling, SDG/ESG alignment, community impact.

Overall TRUFA score

overallTrufaScore is a separate uint32 field on the struct, also validated <=100. It is not computed on-chain from the four dimensions — the validator (off-chain in the backend) decides the composite, then writes all five values together via setProjectApproved.

Weighting: the per-dimension weights used to derive the overall score are decided off-chain by the validator and may be tuned per asset category. The four dimension scores and the overall score are written to chain together; integrators should treat the overall score as authoritative for ranking and the four dimensions as the qualitative breakdown.

Scoring process

1. Validator review. Admin opens the submission with all uploaded documents and metadata.
2. AI-assisted pre-scoring. The platform produces draft per-dimension scores and a rationale to accelerate review.
3. Validator finalisation. The human validator confirms or adjusts each score.
4. Approval. Validator signs and calls setProjectApproved(hash, scores) on the DOBValidator contract (and the equivalent on the Stellar Projects contract).

After approval the scores are immutable: any change to the underlying submission would yield a different SHA-256 hash, which would not match the on-chain record.

Where it shows up in the UI

• Pool cards on Token Studio — coloured TRUFA badge with the overall score; tooltip with the four dimensions.
• Pool dashboard — full validation panel with link to the public verify URL.
• Admin backoffice — aggregate metrics across all validated pools.

Real-world examples

From the methodology doc:

• eHive EV Chargers (Chile) — semi-automated revenue with monthly payouts, expected ~30% APY.
• Rural Solar Microgrids — smart inverter APIs, satellite-verified usage.
• LoRaWAN Gateway Farms (Helium-compatible) — public block-explorer data for uptime + token revenue.

Score integrity

1. Scores are part of the canonical hash that is committed on-chain.
2. The on-chain record stores addedBy and approvedBy so every score change is attributable.
3. Public verify endpoint (/api/public/certificate/verify/:hash) cross-checks the off-chain certificate against the on-chain Project record.

See EVM Validator Contract for the full contract interface and event payload.