- Summary - In order to fully decentralize the backend of ShapeShift, it is vital to have a source of reliable, indexed, and decentralized node data for all chains that are supported by the ShapeShift interface. If anyone is going to host decentralized copies of indexed node data, there needs to be an incentivization structure in place to reward them for their work. Now that Phase 1 of the original FOXChain proposal has been completed, this proposal is being put forth to formalize and fund the development of the new chain based on research of Phase 1 (documented here: https://www.notion.so/shapeshift/FOXChain-0487adc3f52d44a5b74ba40fecddbcf4).
We propose to build Arkeo, a proposed new name, to replace the working “FOXChain” name. This new blockchain will be built on the Cosmos-SDK, to solve these problems as has been discussed numerous times in the ShapeShift DAO community since late last year. The purpose of this proposal is to formalize and push forward the development of Arkeo, a very important piece of decentralized infrastructure that will be used both by ShapeShift DAO and the wider crypto world.
- Abstract - This proposal outlines the second phase of necessary actions to be taken in order to make Arkeo a reality. This second phase will outline the following deliverables to the ShapeShift DAO community:
(1)Building out and launching a functioning testnet based on the technical scope documentation from Phase 1.
(2)Testing and iteration of the testnet once launched
(3)Producing mainnet ready code for a functional blockchain upon satisfactory completion of testnet phase.
(4)Additions and alterations to the Unchained project to support integration with Arkeo.
Additionally, the DAO will need to ratify the proposed airdrop of the new Arkeo token as well as the new name of the chain “Arkeo”.
-
Motivation - There are several motivations for building Arkeo, but primarily it serves as the long-term decentralized backend for all node data the ShapeShift interface will ever need. Arkeo will act as a service for any application requiring reliable access to a consistent interface to any of the supported blockchains. Applications using this service will benefit from increased dapp development velocity, censorship-resistance, and nakamoto coefficient while also reducing reliance on centralized data sources. The motivation for building and producing this solution has only increased since the project was first conceived and Phase 1 was completed. The issue of fully decentralized interfaces and fully decentralized node data has become even more of a prominent problem across the crypto sphere, and Arkeo is well positioned to become the best solution to this important problem across the entire industry.
-
Specification - In order to move forward on the development of Arkeo, this proposal asks for the creation of a purpose-built workstream and appointing Chad Barraford as its workstream leader. The workstream will deliver on (1), (2), (3), and (4) as defined in the abstract. In more a detailed sense this includes:
(1)Chad will lead an engineering team to construct the code of the Arkeo blockchain and launch a testnet when the code is deemed ready to begin such testing. Chad will have control over his team and budget based on the ShapeShift DAO’s definition of a workstream leader (SCP-92). It is expected that Chad will direct and lead the engineering work with the support of 1-4 other engineers of his choosing, plus support from others in the community as resources allow (such as the FOX Foundation in their mission to decentralize ShapeShift and the engineering workstream if appropriate). Ultimately, these decisions will be left up to Chad and the community will be putting their trust in him to make the best decisions appropriate to build and deliver Arkeo. In addition JonisJon has put forward his support to lead Arkeo on the product and community side to help the Arkeo engineering team as part of the workstream. Mperklin, after being the founder and original workstream leader of this project, will continue to be involved in its development in an active advisory role.
(2)Once the testnet has been launched, the workstream will lead a community effort among the engineering team working on the project, testnet validators, potential Arkeo consumers/partners, and other community members to run and iterate on the blockchain’s testnet. During this time it is expected there will be somewhere between 2-4 rounds of testnets and iteration on the code as needed. During the testnet phase the engineering workstream and Arkeo workstream will work closely together to make sure that the API exposed by Arkeo is fit for purpose to be consumed by the existing ShapeShift client, as a “straight swap” replacement, in terms of exposed endpoints and performance. As part of this, the engineering workstream will develop a PoC of the ShapeShift interface hooked up to Arkeo, with any necessary assistance from the Arkeo workstream, in order to confirm that Arkeo node data is working as expected. The PoC will be produced and running internally before Arkeo mainnet launches. The proof of concept is meant to be as simple as possible to vet out the end to end data flow using a single chain with no concern for latency or consensus for data validity.
(3)The workstream will work to produce version 1 of the mainnet Arkeo code based on the learnings from testnet and launch the first version of the mainnet live in production in accordance with the community. The workstream should also deliver documentation and tooling necessary along with mainnet allowing nodes to easily spin up data hosts. With mainnet live, initial distribution of the new Arkeo token and airdrop will commence as the first use cases for ShapeShift and other protocols/DAOs begin to use Arkeo for decentralized node data in production.
(4)Work on Unchained will need to be done in order to support the indexing layer of Arkeo. This work will primarily be done by the current ShapeShift DAO engineering workstream who already built and maintained this layer, however there will need to be some coordination with the Arkeo workstream leader with the engineering workstream in order to make sure that any necessary changes are accommodated.
In addition during the testnet phase, (2) above, the following will be expected to be produced regarding the Client SDK spec:
Client SDK:
Languages:
Golang
Python
TypeScript
Requirements:
Documentation how the Arkeo Client SDK is a drop-in replacement for Infura/Alchemy for the EVM ecosystem
Out of scope:
Client side consensus, i.e. fetching from multiple Arkeo nodes and comparing responses
A large part of launching Arkeo will include the ShapeShift DAO ratifying the proposed airdrop spec along with this proposal so we are ready to launch to mainnet after sufficient testing is complete. The initial proposed airdrop spec is included here: https://docs.google.com/spreadsheets/d/165Q0kj-2zqaiU1bg6WBZfKJ0UoxF2M0n9Zf12_R4lyQ/ Please note while this proposal would ratify the allocation for each bucket as well as guidelines for how tokens will be allocated within the buckets, the Arkeo workstream will still need to determine specific decisions within each bucket. By ratifying this spec, the community would be empowering the workstream to make those decisions as long as the buckets and guidelines are adhered to. Rather than basing eligibility on a single snapshot or series of snapshots, which is subject to gaming, the current plan is for airdrop amounts to be calculated using a rolling balance of all applicable token balances starting from the date this proposal passes and ending 30 days prior to mainnet launch, though still subject to potential workstream revision if necessary. Community members are encouraged to propose alternative distributions during the incubation and ideation periods if they wish to see changes.
In order to deliver on the above Phase 2 Arkeo scope, this proposal requests no further USDC as funding for the moment, as USDC funding is going to be rolled over from phase 1 and from support that has been offered from the FOX foundation. The proposal does however request a proposed team allocation of the new tokens (outlined in the proposed airdrop spec above) which will be allocated by the workstream leader as deemed appropriate among those who contributed in Phase 1 and 2 of Arkeo’s development and will be planned to vest over time after launch of the chain.
A note on the name “Arkeo”, this name is being proposed after careful consideration from the FOXChain team about putting out a brand with staying power across the web3 universe. Anything with block, coin, chain, etc. in the name was considered a non-starter due to the overuse of that type of terminology across the industry. Arkeo (pronounced “ARK-ee-oh”) harkens to the archaeological and archival nature of this new blockchain while at the same time providing a project name that can make the purpose of the chain easily understood with little prior understanding. This is being suggested as the best possible name based on the team’s research and after considering many other alternatives. if anyone in the community wants to suggest what they believe is a better name between now and when this proposal goes to formal vote, please feel free to do so! Assuming this name is accepted by the community, a proposed token symbol will be suggested along with the Arkeo name during the ideation phase of this proposal. Once the proposal is passed and a name finalized, the team will work on putting together branding materials for the new chain. Coinbase Cloud will partner with the Arkeo team to drive co-marketing and branding efforts as detailed in the first FOXChain proposal here: https://forum.shapeshift.com/thread/foxchain-x-coinbase-cloud-support-proposal-40484
-
Benefits - The benefits of this proposal will include the launch of Arkeo, a vital piece of infrastructure needed to decentralize ShapeShift’s backend and also provide the world and other interfaces with essential infrastructure (reliable, incentivized, indexed, blockchain data across many blockchains). In addition to this vital infrastructure, Arkeo will also likely become a significant source of revenue for the DAO over the long term if the project is successful based on the treasury’s proposed allocation in the attached proposed airdrop spec.
-
Drawbacks - The drawbacks of this proposal is that there is no guarantee of success. The DAO will have to trust Chad to diligently put the right people and pieces in place to deliver on the scope laid out in this proposal. It is possible this never gets delivered to a production mainnet. It is also possible that a better solution or other alternative solutions out in the market end up being better suited to solve what Arkeo is trying to solve.
-
Vote - YES - Approve the creation of the Arkeo workstream, approve the proposed airdrop spec and assign Chad as the workstream leader with a mandate to deliver on the scope discussed in this proposal ASAP.
NO - Do not approve the creation of the Arkeo workstream at this time.
