Project Gweihir: Progress Report #2

Hello again! It’s been nearly two months since our last report and we’d like to catch everyone up on the progress of Project Gweihir. We’ve had some setbacks but also some exciting developments! As we get closer to delivering on our Phase I & II milestones, we are getting a clearer vision of how we will implement all Kusama queries (including RPC) to the external adapter for phases III & IV. We are exploring new technologies on the fly as they are released, such as Chainlink Functions and Giant Squid by Subsquid, in order to provide implementers varying levels of decentralization vs ease of implementation. While we believe it’s important to have fully decentralized infrastructure (e.g. running your own full nodes), we realize that it’s important to offer less intensive options to those that can’t afford running all of the components of Gweihir.

Setbacks

Unfortunately, Alex Wang (our Soildity dev) was not attending team meetings starting in late January. He was also not performing any work for the project. It was getting to the point where we needed some test contracts and he was not very responsive. In mid-February, he notified me that he could no longer work on the project so we decided to terminate his contract and seek a different developer for our smart contract needs.

Thankfully, Andrea Vendrame from Tech3Studio (formerly known as Superrisk) stepped up to the opportunity and we got his contract signed on March 20th! Andrea has experience working with smart contract based dApps so we’re excited to have his expertise at our disposal.

To note, we didn’t lose much funds on Alex since his contract didn’t have an upfront payment and he hardly spent any billable hours on the Project.

ETH Denver

Nick, our marketing coordinator, attended ETH Denver where he was able to discover the newest developments on Chainlink, specifically Chainlink Functions. This new technology allows smart contracts the ability to query any public API via trusted node operators on Chainlink’s decentralized oracle network. We don’t know exactly how Chainlink achieves this functionality but we discussed the possibility of implementing it in Gweihir. There’s clearly a trade off between ease of use vs decentralization if we’re using nodes that aren’t our own and APIs that we don’t host. This is how we came up with the idea of “Gweihir Lite” which will utilize Chainlink Functions and a list of public Kusama websockets to bootstrap all of Gweihir’s functionalities without the need to maintain the infrastructure. By leveraging Chainlink Functions we hope to accommodate implementers who might not have the resources necessary to maintain expensive infrastructure or who would like to quickly utilize Kusama chaindata in a smart contract. Unfortunately, Chainlink Functions is still in beta and access is whitelist only. We’ve applied for access with this address: 0x360C59e8153ADB3B1880Ed0733111438657A21f5. Hopefully we’ll be approved for beta access so we can start testing out the tech.

In preparation for ETH Denver, we printed some flyers to hand out to people who are interested in our project. We have a bunch of these leftover so we hope to hand them out at other events:

Tiers of Decentralization

With the discovery of Chainlink Functions and the release of Giant Squid we have decided to establish tiers of decentralization for Gweihir implementations. Here’s a rough overview of the tiers:

• Low: Chainlink Function + Giant Squid API or existing Kusama websocket (no infrastructure)
• Medium: Chainlink node (with ETH API service like Infura) + Gweihir external adapter + existing Kusama websockets
• High: all node infrastructure necessary for Gweihir
• God: all node infrastructure on bare metal or local data center

These will obviously change and mature as we progress, but we will be sure to clearly outline these tiers in our documentation.

While we’re on the topic of decentralization, I thought I’d just mention that we are operating on AWS for now. One thing we’ve discussed as a team is the irony of calling our infrastructure decentralized while it’s running on Amazon’s servers. As such, we have considered moving our Gweihir implementation to a data center once we’ve finished developing the technology. So don’t be surprised if you see data center line items in later phases of the project.

External Adapter/ Infrastructure Progress

Our lead engineer, Spencer, has made some exciting steps forward with the external adapter. If you’re technically savvy you can check out the commits here. In review, he has successfully set up a testing framework and has the external adapter working in a local environment (i.e. query a KSM balance). He was able to come up with a basic smart contract on his own while we were without a solidity dev; now that we have Andrea, Spencer can focus on our dApp backend and the Helm chart for our infrastructure. Next steps will be deploying the external adapter on a testnet and testing it out in deployment.

Websites: dApp & static site

Our frontend developer, Keenan, has been hard at work creating content for our static website and creating the necessary frameworks to display the Gweihir brand. He’s been leveraging his build with AI tools increasing efficiency for the project.

You can check out our MVP static site at www.gweihir.io. We still need to include more content, such as our roadmap and a FAQ, nonetheless it’s really exciting to finally have a landing page. You can check his commits here if you’re technically inclined.

We have also come to an agreement on the design of our final milestone deliverable. This deliverable is a dApp that allows a user on Ethereum the ability to query a Kusama balance using our Chainlink oracle + external adapter. This will be a very simple app but we hope that it will effectively prove the concept and give people an idea of how to implement all of the components of Gweihir into a tangible product. Check it out:

Feedback?

That’s it for now! Feel free to provide feedback, especially if you have any thoughts for our next Treasury spend that we’ll be requesting in a few months. I understand that the ecosystem wants more accountability and we definitely want to be held accountable to our milestones. Do you think Project Gweihir needs a bounty structure? Should we just ask for funding phase III alone? Should we just ask for phases III & IV at once? Any thoughts would be appreciated.

To give you an idea of where we’re at with our funds, we’ve gone through ~33% of our manhours which gives us 66% of budgeted manhours to finish up the static website, build the dApp, continue developing and test deployment of the external adapter, and build container orchestration. It’s my opinion that we will be able to comfortably deliver all of the deliverables given our remaining manhours. At our current rate of progress, my guess is that we are on track for complete delivery in mid-May to early June.

Thanks!