"Blockchain for good" is easy to claim and hard to evidence. When a funder, procurement team, or ESG auditor asks a Stellar-based project what it actually delivered — how many previously unbanked users gained access, how many tonnes of CO₂ were verifiably retired, what each verified outcome cost — a narrative about financial inclusion is not an answer. ISO/DPAS 24874, a Draft Publicly Available Specification from ISO/TC 307 (Blockchain and distributed ledger technologies), is the emerging measurement layer: a KPI framework for evaluating smart contracts deployed in SDG-oriented applications, a maturity benchmarking model, and an alignment methodology that forces every impact claim through an auditable chain. This article maps that framework onto Stellar — its ledger telemetry, Soroban smart contracts, and real ecosystem deployments — so enterprises can measure and report SDG impact the way ISO intends it to be done.
The Context: Stellar's SDG Trajectory
We saw the narrative side of this story first-hand at Meridian 2024 in London: Soroban smart contracts, Stellar Aid Assist, asset tokenization, and a community explicitly oriented toward financial inclusion — themes that align with SDG 1 (No Poverty) and SDG 8 (Decent Work and Economic Growth). Since then the ecosystem has moved from narrative to deployment:
- The UNDP–Stellar Development Foundation partnership (announced January 2025, extended July 2026) researched digital payments across seventeen countries and ran live pilots in Haiti, Syria, Kenya, Guatemala, and The Gambia. In Aleppo, UNDP delivered Cash-for-Work stipends digitally with every transaction recorded on-chain — cutting the estimated cost of distribution from roughly 10 percent of funds under conventional channels.
- The UNDP SDG Blockchain Accelerator, run by the Alternative Finance Lab with SDF as a partner, matched Stellar-based solutions against real UN programme challenges — 46 implementation-ready solutions graduated across the first two cohorts, spanning digital payments, digital identity, traceability, and responsible data use.
- Climate tooling arrived on the network too: StellarCarbon issues CARBON, a Stellar asset where each token represents one Verra Verified Carbon Unit (VCU), with retirements executed in the Verra Registry and mirrored on Stellar for public auditability.
The deployments now exist. What most of them still lack is a standardized way to state — and defend — their SDG contribution. That is precisely the gap ISO/DPAS 24874 addresses.
ISO/DPAS 24874 at a Glance
ISO/DPAS 24874 — Guidance on the use of smart contracts in contributing to the Sustainable Development Goals (SDGs) — is a draft specification developed within ISO/TC 307. One important caveat up front: it is a draft, not a published standard. Its clause numbers and KPI identifiers may evolve before publication, so treat it as a reference framework and version your reports against the edition you used. The draft supports three decisions: whether a smart-contract approach is appropriate for an SDG use case; how to design, deploy, and govern such systems; and how to evaluate them against defined KPIs and benchmarking criteria.
For enterprise readers, the clauses that matter most:
- Clause 5 — Summary for decision-makers. The ten-minute read for sponsors and policymakers.
- Clause 9 — KPI framework. A five-dimension KPI catalogue with measurement approaches, a metadata template, and explicit anti-gaming guidance.
- Clause 10 — Benchmarking framework. A five-level maturity model, scoring and comparability rules, and the SDG alignment methodology in 10.6.
- Clause 11 — SDG-oriented oracles. Design, security (aligned to ISO/IEC 27001), and integration principles for the external data feeds your impact claims depend on.
- Clauses 12–13 — Energy and climate-friendly design. How to account for DLT energy consumption and reduce it in contract design.
- Clause 14 — Supply chain visibility. Traceability guidance relevant to SDG 12 reporting.
The draft's posture is deliberately sober: its own use-case tables mark claims as "intended to contribute to" with the recurring note that attribution has not been established. If you adopt the framework, adopt that discipline too — it is what separates impact reporting from greenwashing.
The KPI Framework: Five Dimensions Mapped to Stellar
Clause 9 organizes KPIs into five dimensions: technical performance, security and oracle integrity, governance and compliance, energy and environmental impact, and SDG impact. Each KPI is expected to have a clear formula, unit, data source, baseline, target, and an owner — documented through the metadata template described below. The table below maps representative catalogue entries to where the data actually lives on Stellar.
| KPI | What it measures | Stellar data source |
|---|---|---|
| T-01 | Execution success rate | Horizon transaction result codes; Soroban diagnostic events for failed invocations |
| T-02 | Mean time to finality | Ledger close (~5 s) via Horizon/node telemetry — deterministic finality, no confirmation window |
| T-04 | Resource consumption per execution | Soroban resource metering: CPU instructions, ledger read/write entries, fee per invocation |
| T-05 | Cost per verified outcome | On-chain fees (100 stroops base fee) + off-chain operating cost ÷ verified outcomes per period |
| O-01 / O-02 | Oracle freshness and mismatch rate | Lag between source event (e.g., registry retirement, IoT reading) and on-chain update; cross-checks against an independent source |
| G-01 / G-02 | Upgrade timelock compliance; dispute rate | Governance logs and contract upgrade history; dispute records per reporting period |
| E-01 / E-02 | Energy and carbon per transaction | Node metering and network estimates — Stellar's SCP is federated BFT, no mining; document boundary and grid intensity (ISO 14064-1 method) |
| SDG-01 | Verified GHG emissions avoided/reduced (tCO₂e) | MRV provider — e.g., Verra VCU retirements mirrored on-chain via StellarCarbon's CARBON asset |
| SDG-04 | Beneficiaries reached | Service delivery records — disbursement recipients, aid program enrolment (off-chain, privacy-respecting) |
| SDG-05 | Financial inclusion: previously unbanked/underbanked users gaining access | Anchor onboarding and KYC records correlated with first-transaction data |
| SDG-06 | Supply chain traceability coverage | Share of products with complete chain-of-custody records on the ledger |
Two properties make Stellar unusually well-suited to this framework. First, the ledger is the telemetry: fees, finality, execution results, and asset movements are natively recorded, so technical KPIs come from the same source of truth as the impact claims — no separate instrumentation layer to audit. Second, Soroban's resource metering gives a per-execution cost in instructions and ledger I/O, which maps directly onto T-04 and feeds the efficiency side of the energy discussion in Clause 12.
The SDG Alignment Methodology (10.6): Two Worked Examples
Clause 10.6 requires every claimed SDG contribution to be documented as a chain: Activity → Output → Outcome → SDG target → Indicator → Data source → Verification method → Baseline → Target → Attribution → Assumptions. If you cannot fill a link, you do not have a claim yet. Here is the chain applied to the two most common Stellar patterns.
Example A — Humanitarian disbursement
| Activity | A Soroban contract releases USDC to verified recipients when programme conditions are confirmed by an oracle |
| Output | Disbursements settle on-chain with immutable receipts; distribution cost falls versus conventional channels (~10% baseline in the Aleppo Cash-for-Work pilot) |
| Outcome | Recipients gain reliable access to funds and, for many, a first transaction account |
| SDG target | 1.4 (equal rights to economic resources and financial services), 8.10 (capacity of domestic financial institutions to expand access) |
| Indicator | UN Global Indicator Framework indicators for 1.4 / 8.10 — e.g., proportion of adults with access to a transaction account |
| Data source | On-chain: Horizon disbursement records. Off-chain: anchor onboarding/KYC, programme M&E records |
| Verification | Third-party programme audit; cross-verification of recipient counts against enrolment data |
| Attribution | Direct for the disbursement rail and its cost reduction; enabling for longer-term financial-inclusion outcomes |
Note the honesty in the attribution row — and note that the draft's own financial-inclusion use case maps to exactly these targets (1.4 and 8.10), which is the same linkage the UNDP–SDF work claims. When your chain lands on the same targets the standards authors used, you are on well-trodden ground.
Example B — Carbon sinking via StellarCarbon
| Activity | An enterprise sinks CARBON tokens — via stellarcarbon.io directly or through an integrated application such as the MozartPay Orchestrated Agreements CLI, which exposes StellarCarbon offset integration alongside its payment and ISO 20022 reporting flows |
| Output | CARBON is sunk on Stellar; the corresponding VCUs are retired in the Verra Registry and mirrored on-chain |
| Outcome | Verified tonnes of CO₂ are compensated — each CARBON maps 1:1 to a Verra VCU from a vetted project (currently a REDD+ initiative in Peru, certified VCS + CCB-Gold) |
| SDG target | SDG 13 (Climate action); co-benefits support targets under SDG 15 (life on land) |
| Indicator | tCO₂e retired (KPI SDG-01), with project-level co-benefit documentation |
| Data source | Verra Registry (the MRV layer) + Stellar ledger mirror (public audit trail) |
| Verification | Registry retirement is third-party verification by construction; the on-chain mirror lets any auditor reconcile independently |
| Attribution | Direct for retired tonnes. Double counting is structurally prevented: retirement in Verra means the unit cannot be resold or re-claimed |
Benchmarking Maturity: From Pilot to Optimised
Clause 10 defines a five-level maturity model. Most Stellar sustainability pilots today sit at Level 2 — KPIs named in a slide deck, no consistent measurement. Climbing the ladder is mostly process, not technology:
| Level | Designation | What it takes to get there |
|---|---|---|
| 1 | Emerging | Ad hoc practices; no defined KPIs — "we help financial inclusion" as an assertion |
| 2 | Identified | KPIs defined but inconsistently measured; no baselines — the typical pilot stage |
| 3 | Defined | KPIs consistently measured; baselines and targets established; governance framework in place — where the UNDP pilots' documented, on-chain evidence points |
| 4 | Operational | KPIs drive decisions; independent verification; continuous improvement loop |
| 5 | Optimised | Benchmarked against industry standards; predictive analytics; full assurance |
The draft is strict about comparability: composite scores and cross-project comparisons are only valid when the system boundary, measurement period, normalisation basis, data sources, and verification quality are equivalent — and material differences must be documented. A "Level 4" claim from a project whose boundary quietly excludes its oracle layer means nothing.
Oracles, Energy, and Climate-Friendly Design
Clause 11 treats oracles as first-class risk: your SDG claim is only as good as the external data feeding it. The guidance calls for decentralized or redundant oracle sources, cryptographic authenticity, ISO/IEC 27001-grade operational security, multi-oracle cross-verification, and explicit timeout/fallback handling — all measurable through the O-series KPIs (freshness, mismatch rate, uptime). StellarCarbon's architecture is a useful reference pattern here: Verra functions as the MRV oracle, and the on-chain mirror converts a trusted-registry claim into a publicly auditable record — exactly the "cross-verification against an independent source" the O-02 KPI rewards.
On energy (Clause 12), the draft identifies four consumption sources — node storage, computation/consensus, inter-node communication, and oracle integration — and recommends event-driven oracle patterns (publish-subscribe, request-response) over always-on listeners. Stellar starts from a strong position: the Stellar Consensus Protocol is federated Byzantine agreement, not proof-of-work, so consensus energy is orders of magnitude below PoW networks. But low is not zero: E-01 and E-02 still require you to document the measurement boundary and carbon intensity assumptions. Clause 13's climate-friendly design guidance — efficient contract code, upgradeable architectures, off-chain computation, embedded climate incentives — reads almost as a description of Soroban's resource-metered design; and where residual footprint remains, the same ecosystem offers the offset mechanism via StellarCarbon.
Reporting: The KPI Metadata Template
The draft defines a metadata template every reported KPI should carry: name, ID, definition, formula, unit, direction of improvement, data sources, measurement frequency, baseline, target, threshold, owner, verification method, limitations and assumptions, and SDG linkage. Reports should be machine-readable where feasible, and include corrective actions taken when thresholds were breached. A minimal Stellar-flavoured record looks like this:
{
"kpiId": "SDG-01",
"kpiName": "Verified GHG emissions avoided or reduced",
"unit": "tCO2e",
"formula": "sum(vcus_retired_in_period)",
"directionOfImprovement": "higher",
"dataSources": ["verra_registry", "stellar_horizon:carbon_sink_txs"],
"measurementFrequency": "monthly",
"baseline": "0 tCO2e (pre-deployment)",
"target": "1200 tCO2e FY2027",
"verificationMethod": "Verra registry retirement + on-chain mirror audit",
"sdgLinkage": { "goal": 13, "targets": ["13.2"], "attribution": "direct" },
"limitations": "Co-benefit claims (SDG 15) not independently verified"
}A practical rollout sequence: pick the SDG targets you plausibly contribute to; run the 10.6 chain for each claim; select KPIs from the catalogue and fill the metadata template; fix baselines before deployment; instrument Horizon/Soroban telemetry plus your off-chain sources; then layer verification — internal consistency checks first, independent cross-verification second, third-party assurance where the audience (funders, regulators, ESG auditors) demands it.
Limitations and Honest Caveats
The draft is unusually candid about failure modes, and your reporting should be too:
- Goodhart's law. A KPI wired to incentives — token rewards, credits, funding tranches — stops being a measure and becomes a target to game. Use multiple complementary KPIs, independent verification, and anomaly detection.
- Attribution, additionality, double counting. Would the outcome have happened anyway? Is another project claiming the same beneficiaries or the same tonnes? Where attribution cannot be established, report "contributing to," never "achieving." Registry-anchored designs like StellarCarbon's solve the double-counting problem structurally; most other claim types have to solve it procedurally.
- Data quality disclosure. State what proportion of your KPI data is directly measured versus estimated, coverage completeness, and the uncertainty in your estimates.
- Oracle trust assumptions. Document provider identity, update frequency, verification method, failure consequences, and fallbacks — an SDG KPI fed by a single unaudited API is an assertion, not a metric.
- Draft status. DPAS documents can change during ballot and adoption. Pin the edition you used in every report, and expect catalogue codes to be renumbered before final publication.
Where This Leaves Stellar Builders
The combination is compelling: a public ledger whose native telemetry answers the technical KPI questions for free, a smart-contract platform with per-execution resource metering, an ecosystem running real SDG pilots with the UN, registry-grade MRV for climate claims via StellarCarbon — and now an ISO draft supplying the measurement grammar that ties it together for enterprise and public-sector audiences. The projects that adopt the framework early will find SDG reporting becomes a by-product of their architecture rather than a quarterly archaeology exercise.
We build in this space: Mozart Pay is our Stellar-based payment platform, and the Stellar Go CLI (the OAs repository) already couples DID-attested payments with StellarCarbon offsets and ISO 20022 reporting — the same pattern of pairing transaction rails with audit-grade records that this article describes. If you are designing an SDG-oriented Stellar deployment and want the measurement layer engineered in from the start, talk to us.
Frequently Asked Questions
What is ISO/DPAS 24874?
A Draft Publicly Available Specification under development by ISO/TC 307 (Blockchain and distributed ledger technologies) titled "Guidance on the use of smart contracts in contributing to the Sustainable Development Goals." It provides a KPI framework for evaluating smart contracts, a five-level benchmarking maturity model, an SDG alignment methodology, and guiding principles for SDG-oriented oracles, energy accounting, and climate-friendly contract design.
Is ISO 24874 a published standard?
Not yet — DPAS denotes a draft at the Publicly Available Specification stage, still subject to ballot and revision within ISO/TC 307. It is usable today as a reference framework for structuring impact measurement, but treat clause and KPI identifiers as provisional and record the draft edition your reporting is based on.
How does StellarCarbon map to the ISO 24874 KPIs?
Sinking CARBON tokens corresponds to retiring Verra Verified Carbon Units — a direct fit for KPI SDG-01 (verified GHG emissions avoided or reduced, in tCO₂e). Verra acts as the MRV/oracle layer, the on-chain mirror provides public auditability, and registry retirement structurally prevents double counting. Its project co-benefits (REDD+ forest protection in Peru, VCS + CCB-Gold certified) can support SDG 15 linkages where verified.
Which SDG targets do Stellar payment solutions typically support?
Most commonly 1.4 (equal access to economic resources and financial services) and 8.10 (expanding access to banking and financial services) — the same targets the ISO draft assigns to its own financial-inclusion use case — plus 10.c for remittance-cost reduction. Climate-oriented deployments add SDG 13, and transparency architectures can support 16.6/16.10-style accountability claims and SDG 17 partnership objectives.
What does "attribution" mean in SDG impact reporting?
Attribution describes the causal link between your system and the outcome: direct (the system caused it, e.g., disbursements it executed), indirect (it contributed alongside other factors), or enabling (it created conditions for an outcome others deliver). ISO 24874 requires claims to be qualified as "contributing to" an SDG target whenever attribution cannot be established with confidence — the single most important anti-greenwashing rule in the framework.
