ETHGlobal Hackathon - DevConnect 2022

ETHGlobal Hackathon Idea:


0xBOTS: Hackathon Submission

web3 mirror | web2 mirror

0xBOTS.eth is an ENS-mediated protocol that enables web2 & web3 frontends to have lightweight compute-enabled distributed backends.


0xBOTS is a web-wide protocol that enables web3 or web2 frontends requiring CPU or GPU time to move beyond centralised backend compute resources. Current generation of IPFS- and Arweave-enabled dWeb frontends are tied down by backend requirements of servers if they intend to serve any data-oriented HTC or HPC content. 0xBOTS protocol is a security-enabled BOINC distributed-computing infrastructure built to provide decentralised and secure high-throughput computing to web3 (or web2) frontends. The communication and monetisation layers in 0xBOTS are mediated by Ethereum, specifically ENS and SIWE. In this prototype however, the monetisation layer is mediated by Lightning BTC Network to keep this hack Solidity-free and fun (writing a price oracle right now is not a priority).


Imagine this…

Supply side: One entity identified by 0xBOTS.eth has compute resources in form of CPU or GPU idle time on a number of big and small devices ranging from servers to smartphones. 0xBOTS.eth is able to manage the compute resources on its devices using a BOINC (Berkeley Open Infrastructure for Network Computing) build residing on its centralised server. 0xBOTS.eth arranges the architecture in a way that resolves to the frontend of the BOINC server. Moreover, subdomains *.0xBOTS.eth map to as many devices as managed by the BOINC server. This mapping has no strict architecture and it is optimisable as a function of types of managed devices. now searches on the web for opportunity to compute, hopefully in return for some cheap $ETH on L2 :gem:, or in this case, $BTC on Lightning Network :zap:[:rofl:].

Demand side: A (web2 or web3) requires resources in form of compute time. It broadcasts a request for computation via the .well-known URI or equivalent located at In the broadcast JSON, metadata provides,

a) the URI of the code to execute,

b) arguments required by the code,

c)’s backend URI for POST, GET requests (, for example),

d) a random key string STR to associate to the request, and

e) a flag (not a necessity but helpful for state verification).

Interaction: The supply and demand side meet when finds a request to compute on .well-known URI of during its routine search for work. Once the request is confirmed to be active via the flag, grabs a nonce from with a GET request and sends a signed POST request to along with a) the random key string STR identifying the compute request, and b) URI where can retrieve the computed output. In the prototype, we will showcase this communication using manual SIWE workflow in Metamask. This framework establishes the required communication layer necessary for the protocol. Needless to say, two additional layers - security layer and payment layer - will be implemented on top to ensure the validity of the computed output and settling payments respectively. In this prototype, we will use ‘integration checks’ [1] for security and BTC Lightning Network for broadcasting and receiving payments via the LNURL-(w/a/p/c) infrastructure (to confuse maxis on either side :nerd_face:). In the final protocol, settling on Ethereum L2s via a price oracle is probably the ideal solution.

[1] Integration Check: It refers to validating the computation by pre- or post-computing a small random subset of the computation to match against the incoming results from the computation provider 0xBOTS.eth

Used technologies: IPFS/IPNS, BOINC, SIWE, ENS, Metamask, LN-BTC.

Demo mirrors: |
Showcase: 0xBOTS · ETHGlobal Showcase
GitHub: GitHub - sshmatrix/0xbots: ENS-mediated protocol that enables web2 & web3 frontends to have lightweight compute-enabled distributed backends


I like the idea you have with this protocol especially since it is bcL1 (Layer 1 becomes confusing when also describing the 7 Layer OSI Model) agnostic:

"Ethereum (Decentralized/Distributed) still runs on the Application Layer of the OSI Model. Maybe clarifying the nomenclature (jargon) to something like this: bcL1 // bcL2 (blockchain Layer Two) or someone else can propose something that is different. "

The greatest asset that this “Universal_Web-Protocol” provides is in it’s integration with Bitcoin’s Lightning Network which can leverage it’s utility within Twitter and provide additional leverage towards its utility and adoption into Web 3 FinTech framework.

Parity Bit:


Adding a parity bit for state verification could speed up total processing time while reducing the load on network utilization.

1 Like