Carbon Retirement

The ECO carbon retirement API simplifies interacting with on-chain carbon markets by facilitating seamless, atomic purchase and retirement of a growing number of supported tokenized carbon offsets.

Programmatic Retirement Lifecycle

To complete the atomic retirement of an arbitrary amount of carbon, you must implement the following programmatic lifecycle:
  1. 1.
    Parameterize the retirement request
  2. 2.
    Sign the returned data using your private key or, for example, the PRVD Vault
  3. 3.
    Broadcast the data and signature to the network for retirement


To programmatically retire carbon using the ECO API, users first create a RetireCarbonRequest.
Parameterize a retire carbon request for signature and broadcast


After creating a parameterized request that can be used to retire the specified amount of carbon, the transaction needs to be signed. We designed the API in this manner to ensure users can enable self-custody in their implementations. The signature over the transaction data returned by the parameterize request provides flexibility for (i) broadcasting the transaction and bearing the network transaction costs or (ii) leveraging the Managed Transactions API to broadcast the transaction while maintaining the ability to verify the original signer (e.g., by using ecrecover).
An integrated code sample will be provided here shortly. You can see how we leverage the PRVD Vault to sign transactions for EVM-based networks here.


This final step in the process to programmatically retire carbon enables flexibility in systems and applications that would otherwise struggle to assemble, encode and broadcast transactions to the targeted network. The broadcast API accepts the unsigned data as returned by the Parameterize call and a hex-encoded signature.
The following code demonstrates how to broadcast parameterized and signed ECO transactions:
curl -i -XPOST \
-H 'Authorization: bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjp7fSwiZXhwIjpudWxsLCJpYXQiOjE1NTk4Nzg1NzQsImp0aSI6IjYzYTJkY2QzLWI5OTgtNDZjNC1hNzFkLTQ5MjU4YTBhYmEyMyIsInN1YiI6ImFwcGxpY2F0aW9uOmNiMjAzN2Y3LTc5ZmMtNDBmNC05NzIwLWFkYTYzNmRhNDE4MyJ9.NQLm__LbMWor-9GMG0LPcH4yQIbu9Uw70kJfRt1KP64' \
-H 'Content-Type: application/json' \ \
-d '{
"data": "c8b9467e0000000000000000000000002791bca1f2de4661ed88a30c99a7a9449aa841740000000000000000000000002f800db0fdb5223b3c3f354886d907a671414a7f000000000000000000000000225b28c1a77fd4493196db19c538a44801243537000000000000000000000000000000000000000000000000000000000000343a00000000000000000000000000000000000000000000000000000000000001200000000000000000000000001480320db0aa1bbef15f847981e28776e7d2c442000000000000000000000000000000000000000000000000000000000000016000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000750726f7669646500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000750726f7669646500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003048656c6c6f2066726f6d207468652050726f766964652045434f20636172626f6e207265746972656d656e742041504900000000000000000000000000000000",
"signature": "4bf45a05a078d2fbd18996ce50f001d3841121b86e6026edff83b5b2aac949f74588378d001687b1b5c85460851952fabb93778c681a4a209a9cf5f25e94823400",
"signer": "0xc9327CB2982cb0B7922670DeF04a11aE5A4E0479"
The broadcast method provides guarantees around atomicity and double-spend protection, ensuring each parameterized carbon retirement request is only executed once. Subsequent attempts to broadcast the same request will fail with a 422 status code. Here is an example response to an API call attempting to retire a parameterized transaction:
"message": "retire carbon request has already been broadcast; tx hash: 584205679a00025e927fc24ef0a3a5e726017392395e7d027b3936d7e644d0ca"

Fetch Carbon Retirement

You can retrieve details related to an existing RetireCarbonRequest, including links to generated certificates and verifiable credentials, if applicable.
Note that the returned RetireCarbonRequest details will contain a non-null tx_hash and cardinality if the request has been successfully broadcast to the network for settlement. The returned cardinality represents the serial position of the completed carbon retirement for the provider for the associated beneficiary_address.
Similarly, the certificate_href and verifiable_credentials_href fields will only be included in the response if the underlying RetireCarbonRequest has been successfully retired and the provider supports those resources on the settlement network.
Some provider implementations may support an additional certificate_href_alt field.
Last modified 7mo ago