HEDGE.earth

Summary

Problem: API requests contribute to 83% of web carbon emissions

Solution: Maximize amount of clean energy used to fulfill API requests

Resolution: 

To this end our contribution to reducing web carbon begins with generating a periodical renewables report of regional grid intensity levels across the globe from the carbon aware api for the next 5 minutes. The generated renewable report is used to redirect API requests to data centers within regions that are using the lowest carbon intense power sources. The API requests are redirected based on reported intensity levels inside the renewable report. Rewriting the definition of a reverse proxy to include the advantage of maximizing clean energy use.

Reverse proxy: An application that sits in front of back-end applications and forwards client requests to those applications. Reverse proxies help increase scalability, performance, resilience, security and clean energy use.

HEDGE is also available as a NPM package. The JavaScript package can be used for websites bypassing the hosted reverse proxy. The API is outlined in the linked Github repository but also available on the demo repository.

We are also publishing a daily report of yesterdays energy grid carbon intensity levels.

Impact

HEDGE has HUGE potential reach and potential CO2 reduction impact, with over 90% of Developers using APIs and emitting 16 million tonnes of CO2 generated each year. HEDGE could be very simply incorporated by hundreds of thousands of APIs to reduce their emissions, aggregating into a large global reduction.

Future Features

• Electricity usage and carbon emission tracking and monitoring.
• Website to submit servcies, track and monitor emissions globally, per org, per servce, region, etc.
• Postman plugin (50 million APIs)
• Serverless Framework plugin to incorporate into AWS API Gateway provisioning
• Nginx and HaProxy extension
• Other configuration as code platforms

The Pitch

To wrap up the three weeks of work, the hackathon will end with pitches of your creations. Pitches are composed of two main parts which mostly override one another in the content but have different formats:

I. Video pitch 

For the video part, you have two strict requirements: 

• no longer than 2 minutes max (only the first 2 min will be considered)

• uploaded to Taikai platform when submitting the project

For the rest, it is up to you, but we recommend structuring the video into 4 parts: 1. the problem, 2. the solution, 3. what you accomplished and 4. finally what you are planning to do next. 

So you have 2 minutes to cover 4 topics. We suggest dedicating about 30 seconds for each topic, but you are free to be more flexible. When showing off the demo, we recommend you not doing a walkthrough and focusing on the 2-3 features that help the user the most. 

The link to the video will have to be submitted alongside to your project page on Taikai by midnight 4th November. 

II. Textual pitch submission on Taikai

Composed of answer to 7 questions that you should prepare in advance before submitting to Taikai: 

• The problem your project solves

• The solution you bring to the table

• What you have done during the weekend

• The solution’s impact to the 

• The necessities in order to continue the project

• The value of your solution(s) 

• The URL to the prototype [Github, Website,...]

If you have any questions, feel free to contact us on the Discord channels.