Solar-electric vehicles on blockchain: one lightyear since Odyssey 2019

With the first event for the Odyssey blockchain and AI hackathon 2020 already taken place two weeks ago, time has gone by lightning-fast since Gimly participated in Odyssey 2019. Here, 100 teams built the most innovative solutions for 20 grand challenges in 11 different tracks, in 48 hours time. 48 hours driven by a crazy mixture of intense energy, deep focus, sleep deprivation, and collective sense of purpose. What does it take for a team to successfully participate in such an ambitious hacking contest?

In this article, I will answer this question by describing my own experiences in being part of the Grid Master’s team in Odyssey 2019. While I will certainly share the solution that we worked on, the focus of this article will be on the process; how did we go from ideation, to design, to development in such a short time? What went well, what could have gone better?Aswering these questions will provide valuable lessons that Gimly is eager to learn and share not only in moving forward to Odyssey 2020, but also in developing and managing future projects for cliënts.

‍

The discovery journey

Our team was put together specifically for the hackathon by Rudolf van Ee (team captain, concept and business development) and Mark van de Kimmenade (concept and business development) from Blockchain Talent Lab. Rudolf and Mark invited me to join their team, bringing in my blockchain expertise and experience in researching stakeholders’ needs and interests to understand the context of innovation. They also invited Sergey Borovskikh (Blockchain backend dev) and Wouter Biegstraaten (UX/UI frontend dev) with whom they had participated previously in Odyssey 2018, and René Ras (fullstack dev). By January, the team was complete and ready to rock.

This gave us four months for our own discovery journey. With a brand-new team like ours, this means not only a journey to discover the use case and plan a solution, but also a journey to discover each other. What are each team members’ drivers and interests? What are their skills and strengths, and how can these complement eachother? And at least as important; what are some of the weaker points in the team that need extra attention? After all, with 20 grand challenges to choose from, and with 48 hours to develop a solution, the best use case and development plan is the one that best fits the team’s members’ strengths and interests as a collective.

Thus, our first task was to identify which of the 20 challenges would be an area where our team would make the strongest contribution. During our team calls and meetings, a near infinite stream of amazing and sometimes not so amazing ideas for different challenges were aired and discussed. I had the pleasure of taking the minutes of our meetings to write down and restructure the spaghetti of ideas, preferences and plans for further discussion in subsequent meetings. We sought to answer the following questions:

• How does it contribute to the objectives of the challenge holder?
• What needs and interests of other stakeholders, including the launching customer and end users, does it address?
• What are the elements of trust, immutability, or instant settlement that would warrant the need for blockchain technology?
• What would be our added value to what other players in the field are already offering?

Soon, it became apparent that the majority of our ideas best fitted the Vattenfall track ‘a fossil free future’, facilitating the societal transition towards renewable energy.

What also quickly became apparent, was that one of our team’s major strengths was on the business and strategy side of things. We aimed for a solution that would not only meet the objectives of the challenge holder, but also one with a clear business proposition and one for which we could identify a potential launching customer in advance. While I mapped out the stakeholders in the Dutch energy system and existing renewable energy related blockchain solutions, Rudolf and Mark reached out to their extensive business network to discuss real world needs in the Dutch energy sector. It was through this extensive network that they found our team’s dream launching customer in Lightyear. Lightyear is an incredibly inspiring and innovative young company set to release the first Solar Electric Vehicle (SEV) – an electric car that is powered through solar panels on its roof and trunk – to consumer markets in 2021.

From here, the product definition phase quickly accelerated. Together with co-founder Tessie Hartjes, we discussed how blockchain technology could help Lightyear meet their primary business interest: to reduce the costs per kilometer for their customers. We discussed how data on solar energy strength collected by a distributed and mobile network of SEVs would help grid operators to predict local power shortages or congestions more precisely and more timely. Once grid operators have established their precise needs to stabilize the local power grid, Lightyear One owners would participate by offering the electricity storage and generative capacities of their SEVs, and would be paid accordingly (see figure 1: SEV to grid integration process flow).

48 Hours of hacking

Taking into account the time constraints of 48 hours of hacking, our team decided to focus on the most important part of the track’s challenge: to help balance the power grid by creating a ‘Mobile Virtual Powerplant’. Thus, we set out to build a protocol enabling SEVs to be integrated to the power grid and provide on-demand electricity storage and generating capacities. For our solution to be viable in the context of real world energy systems, it was important to ensure that the SEV owners would benefit directly from participating in the network, as well as all other stakeholders and actors in the energy system (see figure 2: Placing positive and negative calls/bids for electricity and instant settlements via smart contracts (MVP)). This would require: A) a marketplace where grid operators could place positive (in case of eletricity shortage) or negative (in case of electricity excess) calls for electricity, and where aggregators could place bids to meet the calls, B) a dApp back-end where smart-contracts ensure instant settlement and direct payments to actors in the energy system, C) a dApp front-end for SEV owners as well as grid operators to manage their participation in the network, D) a blockchain to immutably store completed transactions.

‍

The results

So how did we do? Well, as I mentioned, our team excelled in the business side of things. Throughout the hackathon, Rudolf and Mark were in continuous close contact with all the available experts on the energy system and with the challenge holders. Doing so, we ensured that our solution would satisfy both the interests of Lightyear and their customers, as well as the interests of the challenge holders and other actors in the energy system. I ensured the translation of any conceptual changes into blockchain requirements, and Sergey implemented them in the blockchain back-end. Our UI/UX developers Wouter and René worked almost 48 hours straight with near-zero sleep to create beautiful interfaces showing SEV owners their contributions and earnings, and allowing grid operators to place positive or negative calls for electricity. Unfortunately, the 48 hours proved too short to connect these beautiful front-ends and the back-end, leaving us with a great concept that should serve as inspiration for further development more than a functional solution.

More importantly, however, each team member learned invaluable lessons by their participation in the hackathon. We all learned about our own strengths, as well as our opportunities for improvement. We learned how to prepare and operate under such time constraints, how to ensure efficient collaboration, and especially how to grow as part of a novel team. This alone is more than enough reason to participate in a hackathon of this kind.

‍

Lessons for Gimly

For my own work with Gimly, this hackathon provided further valuable insights. With a team like ours – with no pre-existing company or use case, and where all team members have equal say in the solution direction – the team- and use case discovery has proven to be an iterative process. Our product definition was adapted as the interests and specializations of our team members became clearer. When working on projects for a paying client, however, this is not so. Of course, the use case and product definition itself will remain an iterative process that includes the clients objectives, a dynamic context of innovation, and changing technological opportunities. But it should not be affected by the personal objectives and interests of the development team. This is one of the reasons that Gimly’s emphasis is not on in-house development, but on collaborations and partnerships with blockchain development teams that each have their own preferred expertise, types of clients, and use cases. In this way, Gimly can ensure a perfect fit between the client, the project, and the development team to fulfill the clients’ objectives.

My experience with Odyssey 2019 also confirmed another important focus point of Gimly: to put business definition before technology selection. For the hackathon, we worked with hyperledger partly because our developer was most experience with this blockchain technology. And possibly, with Blockchain Talent Lab being the community manager for Hyperledger Netherlands, the strong grounding of our founding team members’ business network in the hyperledger community may also have played a part in this decision. While this worked out fine in this case, because the hyperledger technology fitted perfectly well with our envisioned product, this should not be done so when working on clients’ projects. With clients, it is essential to identify the clients’ business expectations, to identify the interests of the targeted end-users’ and all other stakeholders, and translate these into product requirements before deciding which blockchain technology best fits these requirements. This is, again, an important reason for Gimly to focus on partnerships and collaboration with varying blockchain development companies, rather than in-house development.

‍

Towards Odyssey 2020

So, looking forward to Odyssey 2020, what are the most important lessons for a succesfull participation? Of course, our business and strategy focus remains encredibly important. Who is the client for your solution? Who is the launching customer? Are they in the hackathon jury? Are they in the incubator programs?  What will the jury members be looking for – is it something the truly sparks the imagination, or is it something that can be implemented tomorrow?  

Of course, the point where we could have done slightly better is the most important lesson of all. Going into the hackathon, it is not only important to have a clear idea of your product, but also how the front- and back-ends will connect to each other, and how they will ensure the implementation of your envisioned concepts. While everyone will be focusing on their own roles and specializations during the 48 hours of hacking, frequent collective check-ins on progress made and remaining steps is essential in ensuring effective collaboration.

I am already very much looking forward to another fruitful participation in Odyssey 2020. A new year, new challenges, new teams, and new collaborations! Will you be participating as well? Do you have lessons of your own to share? Please reach out in the comments below, via caspar@gimly.io, or through LinkedIn.