← Back to home

CanaryBay

Come watch canaries hatch, eat, and die, in the newest onchain canary registry. See what is true and what no longer might be.

Screenshots

CanaryBay screenshot 1
CanaryBay screenshot 2
CanaryBay screenshot 3
CanaryBay screenshot 4
CanaryBay screenshot 5
CanaryBay screenshot 6

Problem Statement

CanaryBay aims to implement warrant canary registry on-chain.Warrant canary is used to implicitly convey a message, when explicit communication might not be feasible or possible. This could be due to legal or other reasons. The canary has a message and expiry date. The message could be something as simple as "I'm doing fine", and expiry date can be anything in the future. As the owner of the canary, the audience of the message will understand that the owner is fine, as long as the canary is not expired. As long as the owner feels fine, they can extend the expiry date of the canary, and everything is business as usual. However if something happens, the owner of the canary can simply "forget" to extend it, and expired(dead) canary can be a signal for anyone watching. Warrant canaries are commonly used by companies and organizations like hosting providers, or ISPs. You can also read longer and better description at https://en.wikipedia.org/wiki/Warrant_canaryWarrant canaries are not standardized currently, which makes them hard to find and manage. This project aims to utilize blockchain technology to create a registry for canaries, and allow anyone to create their own canary in the registry. This way, all canaries are public and transparent, and allow for easy deadline extension.CanaryBay allows users to:create ("hatch") new canaryextend ("feed") canary expiry datequery the contract to see if any given canary is aliveset the addresses of allowed feeders of the canaryset the threshold of the canaryset the frequency of the canary (how long is the deadline extended for)browse all canaries hatched on the contractThreshold is a setting that indicates how many feeders are required to extend the deadline. Feeders are addresses that can extend the deadline by 'frequency' amount of time. Each feeder can only feed once during a feeding cycle. After canary is fed by enough feeders, the deadline is extended, and feeders can feed again. If the canary ever expires, it is pronounced dead, and feeding is no longer possible.In web3 world, we imagine such tool could be utilized by DAOs or protocols. Additionally, other contracts could build on a specific canary state. One could build a contract that acts on canary state, to perform other on-chain actions, effectively implementing dead man's switch.Overall we feel like warrant canary is a great fit for blockchain technology, and we aim to make it a public good that can live forever thanks to decentralization.

Solution

The protocol implements push protocol using subgraph protocol integration, so that user's can get notified about canary death, or that a canary is about to expire. Subgraph integration allows us to send notifications without deploying any infrastructure specific to that. The experimental frontend we developed during the hackathon is built using Near BOS technology to keep the frontend decentralized.

Hackathon

ETHGlobal Istanbul

2024

Prizes

  • πŸ†

    Pool Prize

    Chiliz

  • πŸ†

    Best Use of SubgraphπŸ₯‡ Grand Prize

    The Graph

  • πŸ†

    Best Frontend Component Built with BOS2nd Place

    NEAR Protocol

  • πŸ†

    Pool Prize

    Arbitrum

  • πŸ†

    Deploy on Scroll

    Scroll

Contributors