(SCP TBD) ShapeShift FOXChain Proposal (Phase 2)
Nov 8, 2022


1. 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).  

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. 

2. 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”.

3. 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.

4. 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.
  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.


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. 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.

5. 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.

6. 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.

7. 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.

This post has 1 history
Reply
Likes
Tip
27 Comments
Latest
Oldest
guest
Write a reply...
0xean
Read More
0xeanNov 13, 2022

Thanks for getting this out there @jonisjon - very exciting to see the progress thus far on Arkeo.

A few questions and comments:

  1. "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." I think it may be good to strengthen the language here. While I know that there are broad use cases for arkeo beyond the SS application, it would be great if the language ensured that 1) before arkeo is launched the integration points will be signed off on by the Engineering workstream and 2) before the completion of this phase of the arkeo workstream, a working POC of the SS app powered by Arkeo will be created.
  2. re: the airdrop - I think we can use the tokens that are currently allocated to other Ethereum DAO's in a much more effective manner if they are used as incentives for integration vs. airdrops (as mentioned in the doc). I personally would love that decision to be made by governance vs by the arkeo workstream. Many of these same DAOs and users have been airdropped FOX in the past, so if they have held, they will get the new token either way.


A general comment to my fellow foxes:

I think this proposal is critical to the future of ShapeShift. It has broad implications for the SS treasury, governance, community and more. The creation of a new token, a new DAO and product is something we should have more conversation and engagement on. Alongside the huge potential of this project are also many risks we should be comfortable with. There was lots of conversations over the last few months in discord on some of these topics and hopefully anyone with concerns voices them here on the forum before this goes up to vote.



5
jonisjon
Read More
jonisjonNov 13, 2022

Hey @0xean  - thank you for the reply and support on this!

Regarding your specific points:

  1. Do you have proposed language for this you would like to see that would strengthen it? The reality is that in conversations between Chad and the engineering workstream so far is that Chad doesn't actually believe any changes to Unchained will be required, however I still have this section here in case that it turns out there are changes needed. We could alternatively strike this language all together, but I currently prefer to keep it in it's current form. That being said, I would be uncomfortable adding anything that requires engineering workstream signoff in order to launch Arkeo, they are a small team with their own priorities and I don't want to add potential blockers here that are unnecessary. They will of course be included in many converstations as things develop and I don't expect this to be an issue with the collaboration I am already seeing, but I don't want to put some sort of structural check here that would stop Arkeo from launching if the Arkeo workstream leader deems it ready to go. Similarly while I expect that a version of the SS app powered by Arkeo will indeed be ready to go either before or slightly after Arkeo launch, I am not sure that it makes sense to add that as a requirement of this workstream as this WS would not be the ones working on that. Ultimately that will be up to the product/engineering workstreams to coordinate and make sure they get that done within their own priorities and timelines so I don't see the benefit of adding that external dependence here to the Arkeo WS. That being said, Chad has stated the goal here is to make this as simple as possible to integrate Arkeo in order to swap out other node providers and I expect that the SS app will be the prime candidate to be testing this during the testnet and right at launch and doubt this will become any sort of problem.
  2. I definitely see that point around the Airdrop, and to re-iterate what is already in the airdrop doc, that list of DAOs is just an example list, by no means final. If the community would prefer to see this done in a different manner or perhaps some portion of it split into airdrops for those DAOs but another portion held back as incentives for integration that is something I would probably support as well. Please fork the doc and propose a different way of doing things if you think that is the right way to go!


3
jonisjon
jonisjonNov 14, 2022

If we want to add language to (4) in the spec somewhere along the lines of “it is expected that the Arkeo workstream will work closely with the engineering workstream to make sure they are comfortable with integration points as well as assist with anything needed to get up a PoC of the ShapeShift App working with Arkeo” I think that would be fine. I would just stop short of any sign off or anything that creates an unnecessary external dependency for the Arkeo workstream to deliver on its mission.

1
0xean
Read More
0xeanNov 14, 2022

Thanks for the response - I would be uncomfortable with out some sort of checks and balances here.

There is immense upside for arkeo to launch regardless of it fitting the exact need for Shapeshift. Especially with a separate token involved. Given that SS funded the start of this whole thing, SS should be in control of the final sign off and ensuring it meets the goals of SS and the engineering workstream.

While engineers may think there will be no changes required and that the integration will be smooth and easy, de-risking this with a POC is critical. We are all moving quickly and the potential for miscommunication or misunderstanding disappears once a POC is created between the teams. Changes may become much more challenging post launch of the blockchain and I am unsure why there would be contention from creating a POC before a major product launch.

1
jonisjon
Read More
jonisjonNov 14, 2022

Well the ShapeShift DAO is of course in control of it via this governance process, I think the question is whether the engineering workstream should be in any sort of control over the Arkeo workstream in this case once it is created.

I don’t think putting language into the proposal which essentially creates engineering requirements of a different workstream (sign off on integration points/ a PoC that the engineering workstream would build) really makes sense here. I guess I would like to hear from the engineering workstream leader on this specific issue and if he suggests language along those lines that makes sense happy to work to incorporate that.

I think this would be different if this was creating changes to the app the workstream had to merge in, but that is not the case here as this will live separate from the current interface in its own repo. Ultimately I support the goals you are talking about (I fully expect the engineering workstream to be working closely with the Arkeo workstream to make sure the integration points look good and that they will create a PoC using Arkeo, hopefully it is very easy to do if we build this right) we are only splitting hairs around requirement language in the proposal here.

1
joshuAF
joshuAFNov 15, 2022

In general, I'm very supportive of this.

Is there enough leftover from the Phase 1 budget to fund this workstream with 1-4 engineers for the time needed to launch this new chain?

1
0xdef1cafe
0xdef1cafeNov 15, 2022

While I don't want to unnecessarily insert myself into the process here, I do think it's important we collaborate here and ensure that the original design intent (decentralize the SS backend) is met, and the Arkeo solution is fit for purpose.

It's also good to have a reference implementation we're able to point the community to for the purposes of developer relations - "here is how Arkeo works for ShapeShift".

4
0xdef1cafe
0xdef1cafeNov 15, 2022

"We are all moving quickly and the potential for miscommunication or misunderstanding disappears once a POC is created between the teams. Changes may become much more challenging post launch of the blockchain and I am unsure why there would be contention from creating a POC before a major product launch."

I'm 100% in alignment with this, we need to demonstrate this end-to-end well before launching.

2
jonisjon
Read More
jonisjonNov 15, 2022

Yea I think we are all aligned on the goals here, the question is what if/any changes to the language of the proposal are needed to reflect that without causing undue burdens on the new workstream which are out of scope of what it is trying to deliver (e.g specific work from another workstream)?

Would my suggestion here work? https://forum.shapeshift.com/landing?method=share&thread=scp-tbd-shapeshift-foxchain-proposal-phase-2-41034&post=1951145&refer_id=28625

Or if not what do you suggest?

We can also chat about this during the scheduled regular meeting today and see if we can come to an agreement with all stakeholders what the language should reflect.

1
jonisjon
jonisjonNov 15, 2022

Yes, as currently budgeted there is enough to get to this launch with the resources we believe are needed as planned.

1
ShapeShift
Welcome to the official forum for ShapeShift DAO. Learn more at shapeshift.com
1.4K
Members
4.2K
Posts
About this Discussion
27
Comments
19
Participants
Pinned in Home
FOX Governance Process
How to link legacy forum history to your Metaforo account
Anonymous Feedback Submission Form
Pinned in 🏛️ Proposal Discussion
🏛️Proposal template and instructions
More From ShapeShift
[Incubation] Added fees for Thorchain swaps
Engineering Workstream Renewal, February - May 2023
[Incubation] Salary Caps for Workstream Leaders