Adam Menary (xpollinate)

Co-Founder & Director

Adam has a Bachelor of Agricultural Science with Hons. Adam has 30 years of experience in supply chain management and has developed an assortment of related technology solutions. Adam undertook the first ISO 31000 supply chain studies for Beef and Dairy from Australia to the USA, which was tabled as the basis for a bilateral trade agreement under the Bioterrorism Act. Adam has overseen the integration of blockchain technologies into existing commercial products. He is passionate about real action on climate change and a co-founder of Beyond Zero Emissions, which has become one of Australia's leading think tanks on climate action.

LinkedIn: adammenary

Twitter: @AdamMenary

Keybase: @Xpollinate

Alex Olieman (convergence)

Co-Founder & Lead Engineer

Since 2020, Alex has become more active in the Stellar community because he got absolutely hooked on Stellar Quest. After a decade of commercial software development and academic research, he wants to introduce regenerative projects to the Stellar ecosystem. Alex is a generalist with a background in Industrial Design Engineering, a Bachelor of Science in Future Planet Studies, and a Master of Science in Information Studies. Several of Alex’ long-term interests have come together in Stellarcarbon, and he is very much looking forward to spending more time on its further development.

LinkedIn: alexolieman

Google Scholar: Alex Olieman

GitHub: aolieman

Keybase: @alioli

Hendrik Grondijs (henkieee2606)

Lead Developer

Hendrik has extensive experience in full stack web development, data science, and mobile app development. He has a Bachelor of Science in Econometrics and a Master of Science in Statistics. In his spare time he produces his own music, and has fun tinkering with new applications of AI, or "superpowered statistics", as he would call it.

Website: hendrikgrondijs.nl

GitHub: hlgrondijs

• SCF#11 Stellarcarbon - $37k awarded

Develop a user interface that connects to popular Stellar wallets

https://github.com/stellarcarbon/sc-checkout

The prototype of our retail-oriented checkout UI was further developed in several iterations. It was converted to use Typescript and we decided to use StellarWalletsKit instead of the initially selected options to let users connect their software wallets. The error handling was significantly improved, helping users out with clear error messages that are shown in the related UI components.

We originally planned to incorporate this dedicated checkout UI into our existing Wordpress website, but weren't satisfied with the limitations that we were faced with. This dedicated checkout UI currently serves as a functional demo, and as a reference implementation showcasing the use of an automatically generated Typescript client for our Stellarcarbon API.

Website redesign

https://github.com/stellarcarbon/sc-website

We've completed the first phase of rebuilding our website as a web app that allows users to connect their wallet, sink carbon, and manage their account. In this phase we've delivered a retail-oriented user interface, and have provided the foundations that will help us complete the next items on our roadmap more quickly. The overall design and interactive features have been implemented. Our website's content needs to be updated to reflect the developments in the voluntary carbon market—e.g. we're transitioning from "offset claims" toward facilitating "contribution claims"—and we have writing work left to do.

Some highlights of our new website:

• integrated retail functionality
• (personalized) activity overview
• recent activity showcase on the homepage
• mobile-first single page web app

Continuous monitoring & auditing tools

Stellarcarbon wants to provide transparent access to real world assets (eco-credits), and to do that we need to go beyond the proof-of-reserves that's linked in our stellar.toml file. Based on user feedback, we need to separate the concerns of retail users and our integration partners.

We've added two API endpoints that provide access to our inventory and retirement data in the Verra Registry. This provides a more convenient way for integration partners to see which credits we have available for retirement, and to verify that sinking carbon through our service has led to the correct retirement details in the registry. We provide a higher level overview for retail users on our new website. This takes the shape of a table that shows the overall state of our accounts, and the sum of pending retirements that have yet to be finalized in the registry.

Other API improvements

The documentation, error handling, and schema-based client generation has been significantly improved. By using the OpenAPI schema as the basis of API clients in two of our own repositories, and in a new partner integration, we've had ongoing feedback on how to improve it. We've moved more of the documentation inline to streamline working with our API in an IDE. New schemas have been specified for error responses to give developers better options for handling errors, rather than relying on users to do so.

Partnerships

CFCE has been developing the GiveCredit app, which allows donors to retire eco-credits through Public Node using Stellarcarbon's service. Being able to work closely with another team has informed the extension work on our API, and has been very helpful in clarifying how to incorporate Soroban into our roadmap.

In this sub-project we will tackle the fractional retirement of eco-credits. Until now, the Stellarcarbon service only worked well when whole credits were retired. Traditional carbon registries do not and will not support the retirement of fractions of credits. Although there's absolutely nothing wrong with rounding up contributions to ecosystem restoration and climate mitigation, Stellarcarbon wants to address the part of the market that is not served well by this limitation.

To date, several real Stellarcarbon transactions have been done that show the limitations of our current service regarding fractional retirements. There's a transaction corresponding to the emissions caused by a business trip of just over 3 tonnes, and another of less than 1 tonne. These transactions can't yet be finalized in the registry and they contribute to the amount of pending retirements. There's also a chain of transactions corresponding to a decade of flight emissions, which could be finalized only because a "rounding" transaction was added to the end of the chain. The user had to manually tally their emissions and calculate how much needed to be added to arrive at a round number. With this approach, a user who might not want to make an additional contribution would be stuck.

Our implementation of fractional retirements allows:

• small contributions to add up to whole-tonne certificates for a single account
• larger contributions to neatly align with emissions estimates (e.g. 3.142 tonnes)
• one-off contributions to be bundled, with an on-chain record of individual contributions.

The work on fractional retirements can be separated into five distinct layers: database, API, user interface, Soroban interface, and legal.

Database

Stellarcarbon prefers to minimize its energy usage. So far, we haven't had to operate our own database. We've gotten by using only the Stellar ledger and the Verra Registry as persistent storage. Implementing fractional retirements changes this. Providing a good user experience is no longer feasible when data from Horizon and the Verra Registry need to be queried and joined each time a user wants to view or change the state of their account. We need to store data on the Stellar transactions that users do through Stellarcarbon, the retirements that we finalize in the Verra Registry, and particularly on the relations between them.

We want interested third parties to have access to the same data that we do, in order to independently verify that Stellarcarbon is operating with integrity. The majority of our database tables contain public information. We will implement the core of our database logic in an open-source repository, and will provide simple instructions on how to fill the database from the original data sources, as well as check the state of our issuance and retirement process. Please see our technical architecture document for details on our database.

Stellarcarbon API

The account management functionality needs to be exposed by our API. It will be extended with endpoints that list an account's transactions and their status, and view all retirements associated with an account. The existing registry endpoints will be deprecated and replaced with views on Stellarcarbon's inventory and retirements that are populated by the database. A retirement detail view will also incorporate the relation with transactions, and shows a breakdown of the amount of credits retired. Lastly, an endpoint needs to be added which allows a user to ask that Stellarcarbon immediately retires the credits that correspond to their pending balance.

Several improvements are needed to ensure that fractional retirements can be processed smoothly. A background job needs to be added to the backend to ensure that users won't need to take any action for their pending retirements to be finalized when they add up to a round number. Another job will query the database for pending balances older than e.g. 90 days, and bundle them into a collective retirement. We also need a new staging deployment to facilitate integration testing. Our current version is not consistently available on testnet because Verra lacks a testing/staging environment. After we have implemented our database, we can sufficiently mock Verra data to make a staging environment that writes to testnet available at all times.

User Interface

The fractional retirement functionality will be located in the account management interface that we've already started to build. We want to present fractional retirements to users as an integral part of Stellarcarbon, rather than as a separate feature. Our integration partners have implemented their own frontends for end-users to sink carbon, but we expect our website to be the main hub for account management for their users as well as our own retail audience.

We've designed our user dashboard to have its functionality split into three tabs, to: sink carbon, proceed with pending retirements, and view past transactions. On the pending retirements tab, users will be able to see how much additional carbon they'd have to sink to obtain their next individual retirement certificate from Verra. Alternatively, users with a pending balance of at least 1 tonne may choose to immediately request a certificate for their whole tonnes. The tab will also show for each transaction when their right to an individual retirement certificate will expire, after which the transactions can be bundled with those of other users, leading to a collective retirement certificate.

Soroban

Stellarcarbon needs to expose at least some functionality through Soroban. Our integration partner CFCE has been writing smart contracts to automatically split donation payments, and to emit a contract event whenever the funds that are accumulated to be used for credit retirement exceed the price of 1 tonne. Without the ability to actually sink carbon from within a Soroban contract, we're left with an annoying manual step in this integration. We want to develop a simple smart contract that allows the atomic swap of our payment token (CARBON) for our locked retirement token (CarbonSINK) to be done with Soroban. The Stellar Asset Contract will be used to interact with the existing tokens.

It is paramount to maintain our operational security, and we expect some challenges relating to the use of the CarbonSINK issuer keypair in authorizing transactions to occur on Soroban. We want to initially only publish this smart contract on testnet to allow for sufficient time to test the integration together with our partner, and to have as much time as we need to consider the security implications of launching the contract on the public network.

Legal

By deviating from our current "sink one tonne on Stellar, receive a certificate for one tonne from Verra" model, we're increasing the need to clearly explain the terms that govern the use of Stellarcarbon's service. It doesn't change the fundamental principle that Stellarcarbon retires eco-credits on behalf of its users. The conditions under which users can obtain an individual retirement certificate from Verra, however, become more complicated. Some kind of expiration on pending retirements is necessary because they require Stellarcarbon to hold a credit in its inventory that has already been reserved by a user. The liability corresponding to the total pending balance needs to be bounded, because letting it grow forever would pose risks to both Stellarcarbon and its users.

We'll draft the terms of use ourselves, after which we can get a legal consultation. Once the terms have been published on our website and are linked to from our API, we'll be able to launch our retail-oriented service. Making standard terms available will also facilitate the integration of our API into other products and services, reducing the need for separate partnership agreements.

[Deliverable 1]

    Database schema and filling from Horizon and the Verra Registry
    How to measure completion: sc-audit repo on GitHub includes methods to set up a local database, load minting & sinking transactions from Horizon, and to load retirements from Verra.
    Estimated date of completion: 6 weeks after community award announcement
    Budget: 40 hours development + 10 hours testing x $100/hr = $5000 [lead: Alex, support: Hendrik]

[Deliverable 2]

    Database logic to compute inventory and pending retirements views
    How to measure completion: sc-audit repo on GitHub includes methods to fill m2m tables, to view the status of sinking transactions, and to view the current inventory.
    Estimated date of completion: 8 weeks after community award announcement
    Budget: 20 hours development + 10 hours testing x $100/hr = $3000 [lead: Alex, support: Hendrik]

[Deliverable 3]

    CLI, packaging, and containerization
    How to measure completion: the sc-audit repo can be installed as a python package which can also be used with a `docker run` command. Methods to fill the database and get table views on the inventory and pending + completed retirements are callable from the command line.
    Estimated date of completion: 8 weeks after community award announcement
    Budget: 10 hours development + 5 hours documentation x $100/hr = $1500 [lead: Alex, support: Hendrik]

[Deliverable 4]

    Database dump and restore tool
    How to measure completion: the sc-audit CLI can be used to dump core database tables in a diffable format. The data loading commands can either restore dumps and catch up from the original data sources, or do a fresh load from the data sources.
    Estimated date of completion: 10 weeks after community award announcement
    Budget: 15 hours development + 5 hours testing + 5 hours documentation x $100/hr = $2500 [lead: Alex, support: Hendrik]

[Deliverable 5]

    Stellarcarbon API endpoints
    How to measure completion: the Stellarcarbon API includes endpoints to list an account's transactions, view an account's retirements, request the retirement of a pending balance, view the current inventory, and list all finalized retirements.
    Estimated date of completion: 10 weeks after community award announcement
    Budget: 40 hours development + 10 hours testing + 5 hours documentation x $100/hr = $5500 [lead: Alex, support: Hendrik]

[Deliverable 6]

    Stellarcarbon API staging deployment
    How to measure completion: a staging version of the Stellarcarbon API connects to testnet and can be used without the need for real money. It has a mock connection with the Verra Registry that enables the testing of retirements.
    Estimated date of completion: 12 weeks after community award announcement
    Budget: 30 hours development + 10 hours testing x $100/hr = $4000 [lead: Hendrik, support: Alex]

[Deliverable 7]

    Stellarcarbon API background tasks
    How to measure completion: the staging API updates the database after a sinking transaction is successfully submitted. If the user's pending balance can be automatically retired, the retirement is finalized after an artificial delay. Any pending balances of a predefined age are bundled into a collective retirement.
    Estimated date of completion: 12 weeks after community award announcement
    Budget: 25 hours development + 10 hours testing x $100/hr = $3500 [lead: Alex, support: Hendrik]

[Deliverable 8]

    Fractional retirements UI
    How to measure completion: the user dashboard is split into 3 tabs, including a pending retirements tab. A user can proceed by doing a new sinking transaction that rounds up their pending balance to a round number, or by requesting a retirement certificate for their whole tonnes. The expiration date is shown for pending retirements, and any collective retirements toward which the user has contributed are shown besides individual retirements on the past transactions tab. A staging version of the website will be provided to measure completion of this deliverable.
    Estimated date of completion: 12 weeks after community award announcement
    Budget: 50 hours development + 20 hours testing x $100/hr = $7000 [lead: Hendrik, support: Alex]

[Deliverable 9]

    General UX improvements
    How to measure completion: a "software" page is added to the website with clear instructions on how to get started with the integration of Stellarcarbon into a product or service, and how to monitor/audit our operations. The website looks and feels production-ready. A usability testing report is provided.
    Estimated date of completion: 12 weeks after community award announcement
    Budget: 40 hours development + 40 hours usability testing x $100/hr = $8000 [lead: Hendrik, support: Alex]

[Deliverable 10]

    Soroban contract to sink carbon (testnet)
    How to measure completion: use the contract on testnet to do an atomic swap of CARBON for CarbonSINK, providing retirement details in the contract call. The CarbonSINK balance is locked onto the recipient account, as it is when the classic API is used to sink carbon.
    Estimated date of completion: 12 weeks after community award announcement
    Budget: 40 hours development + 10 hours testing + 10 hours partner testing x $100/hr = $6000 [lead: Alex, support: CFCE]

[Deliverable 11]

    Terms of Use
    How to measure completion: Stellarcarbon's terms of use are clearly visible on the website, and need to be explicitly agreed to when a user connects their wallet.
    Estimated date of completion: 12 weeks after community award announcement
    Budget: 15 hours writing + 15 hours iteration x $100/hr + $2000 legal fees = $5000 [lead: Adam, support: Alex]

Regenerative finance (including climate finance) is becoming increasingly important, and is expected to grow significantly in the coming decades.

2024Q3

• Launch Stellarcarbon for the retail audience that exists on Stellar
• Complete our Soroban interface for GiveCredit (CFCE) and other partners
• Develop educational content on the ICVCM Core Carbon Principles, and the VCMI Claims Code of Practice

2024Q4

• Expand our team with core members and volunteers
• Ramp up our marketing efforts
• Develop a portal that helps companies capture their sustainability commitment, and shows their progress in reducing emissions within their own supply chain

2025 and beyond

• Work with a technical partner to provide affordable monitoring for climate projects, using earth observation
• Enhance the showcasing of sustainability progress for our business customers by machine reading the documents that they are required by law to produce
• Allow our audience to report possible misleading claims (i.e. greenwashing) based on the use of our services, and issue warnings and/or corrective action when our terms have been violated

We realize that some of our 2025 and beyond goals may seem outrageously ambitious, given where we currently stand. Based on exploratory talks with impact investors, it will be easier to attract external funding for ambitious ideas that solve real world problems than for incremental progress. We expect to fully staff our team before we embark on this journey.