Ideation Post: (SCP 111 ) ShapeShift FOXChain Proposal (Phase 2)

[jonisjon]

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

[jonisjon]

Ideation signaling vote is now live on snapshot: https://snapshot.org/#/shapeshiftdao.eth/proposal/0x7d9f1986040a2a4be2b473500f9b452e560a6ea9fed5d4ed6200157d3ccbfd3e

Changes from incubation include the changes noted here: forum.shapeshift.com/landing?method=share&thread=scp-tbd-shapeshift-foxchain-proposal-phase-2-41034&refer_id=28625&post=1951237 and here: forum.shapeshift.com/landing?method=share&thread=scp-tbd-shapeshift-foxchain-proposal-phase-2-41034&refer_id=28625&post=1951256

[hornyfox]

1. The Dev Fund is 10% of the entire total supply for potentially less than a dozen individuals yet $fox holders receive 8%? (33% of 25% with eligibility determined by devs). Nb. This seems more of a love job for Chad anyway considering he can already buy the FTX love nest from the administrators.
2. The specifics of the airdrop should be decided up front. The buckets being defined is no protection against getting shafted by devs determining the nuances and specifics of the eligibility. Why can't this be decided up front or progressively elaborated through governance?

[Fireb0mb1]

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.

Could you provide more details on what the Foundation “support” consists of please? As it is mentioned in the context of USDC funding in the beginning of the sentence, is there any financial ties between the Foudnation and the potential future Workstream? If so, why has this route been chosen instead of requesting funds from the DAO through a proposal?

[jonisjon]

Hi Hornyfox, thanks for the questions/comments.

To respond best I can:

Yes, that is the proposed fund for development over time, this is mainly being used to incentivize the longevity of the team working on this, and is mostly done in lieu of any significant upfront payments today. The main goal is to bootstrap this with as little use of the DAO treasury as possible and this is a way this is being done. Also your numbers are incorrect around FOX holders who right now will get aprox 10% of the total supply as well under the current spec. That being said if you think there is a better way to structure the airdrop, please suggest it, we had some suggestions during the incubation phase which were incorporated and if the community aligns around a different way we can certainly change things still.

We tried to incorporate as many of the specifics as we could, but there is a number of items that will need to be figured out once the chain is farther along towards launch around the snapshots, formula methedology etc that will become highly technical and we currently believe the dev team will be the best to determine some of those specifics. If you have specifications you want to be suggested now, or if governance wants to align on those and pass something later to formalize it regardless of what workstream may otherwise implement. then I have no issue with that, but I want to make sure we can keep moving forward rapidly (with other potential competitors to this chain preparing to launch) and right now I do believe this is the best method to get community buy in on this plan upfront and move things forward.

[jonisjon]

Hey Firebomb, thanks for the questions - Foundation support consists of two aspects: (1) limited financial support (they see this as a crucial part of their mission to decentralize ShapeShift) and (2) engineering support from Foundation resources. Both these aspects were written into the current proposal, I apologize if this wasn’t clear and am happy to update the language after ideation to make it more clear if you think that is help.

This route was chosen primarily just as a way to boostrap and get this project launched with as little impact on the DAO treasury as possible (the DAO is still offering some direct support on phase 2 with the rollover of un spent funds from phase 1). This seems like a great way to handle things from my perspective because we can get the support we need without having any large expenses to do so, if the community would prefer to spend additional funds from the treasury to support this project we could incorporate that into the proposal, but I am not sure that would make much sense when we can get this done with such limited impact on the DAO treasury and runway which I see as a huge win.

[Fireb0mb1]

Hi, thank you for the answer!

For the sake of funding/budget transparency and so its easier to know what has effectively been spent by the DAO/Foundation on this project, could you maybe include a breakdown of what has been received and what’s left to spend before Phase 2 starts?

It might give a better idea to the community if the operational budget matches the stated ambitions and help everyone form a more informed vote. I know that there’s no additional funds requested in this proposal but I think it can be an interesting data point to share in public.

[jonisjon]

Sure my understanding is that 100k is still available and being pulled over form phase 1 to help fund phase 2. The foundation is offering limited support of up to 20k/mo on top of that for the next 4-6 months.

In terms of the full accounting of what has been received/spent during phase 1, I will have to ask @mperklin to weigh in on that since he was the WS leader during that time and I believe has those details (I was involved as a pro-bono advisor during phase 1, but was not privy to any details of the budget beyond that at the time).

[jonisjon]

@Fireb0mb1 - got more of the specifics from @mperklin: Of the 300k USDC budget the FOXChain WS received during phase 1, 191k was spent during the research/architecture phase. So as currently planned, 109k USDC will rollover, and the remaining mentioned above will be supplied by the foundation to get us to launch.

[Fireb0mb1]

OK, thanks a lot for the details!

[willy]

Thanks for the questions @Fireb0mb1. @jonisjon covered well, so I’ll just add a few points.

The Foundation’s mission is to support the DAO in achieving full decentralization, and I personally can’t think of a better way to do this than by supporting things like the development of Arkeo to replace ShapeShift’s backend (one of the final bosses!). To this end, we’ve committed $20k/mo for up to 6 months as well as development resources (aka 0xean and Adam) to help bring Arkeo to launch. This is all pro-bono, and there are no other financial arrangements between the Foundation and Arkeo whatsoever

Happy to answer any other questions if you have them

[Fireb0mb1]

Thanks for the clarifications! I think it’s a good decision by the Foundation and am glad everyone gets to be informed of these details. The more transparent everything is, the less shadows can be cast on what we’re trying to achieve in my opinion

[Giantkin]

1. ok, a few contention points ive heard. i dont grasp the nuances totally, but its def around this section, where i can see some vague wordage

1. -quoted from forum/ideation-

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

–end quote.

1. Maybe a tighter defined aspect around the Arkeo workstream determining the decisions in each bucket. I think (my opinion) is that the naysayers are thinking the DEV's will have full control of such. and not the Chain token voting holders. (which would be everyone in the 'airdrop' initially)

1. Now that i say that, i realize the WS is specially pointed as being in control. maybe we set out the exact 'guidelines' that were mentioned for those decisions?

1. Each 'bucket' is seperate, would the Arkeo WS have control of items inside of Each bucket? and what are the choices that they would be able to make. (and whats the stopping point of such)
2. make it more clear for me at least.

1. ofc, the only one that has any variables that are visible, is the airdrop bucket.

1. in the airdrop tab, notes section, the items are listed that the WS would have to determine yet. but in the proposal, they are not listed. Maybe list them as the restricted items that can be determined via the WS?

–hoping im not way off here

Sorry, formatting copied from discord.(i cleaned it up a bit, but not totally)

[Giantkin]

Figured i would copy out the Bucket notes, maybe they are missed.

These only pertain to the ‘airdrop’ Section (bucket is used in here, i think i used it overall incorrectly)

A)The community delegates authority to the Archeo development team to determine the final specifications within each bucket described above. However, any changes to the buckets would require an additional proposal.

A1)Further, the community delegates authority to the Archeo development team to decide the following:

1. Should airdrop recipients be required to complete actions to receive their airdrop?

2)Should airdrop be immediately claimable or have a vesting period? If there is vesting, should airdrop recipients be able to delegate and earn yield with their locked tokens?

3. How long should airdrop be claimable/decay? Unclaimed drops will be returned to the community treasury

4. If you qualify for multiple buckets, should your rewards get multiplied? I don’t think we can do this without modifying the bucket allocations

please discuss each point above Separately, to avoid confusion. (mine mostly)

-these points taken from the Archeo Distrubution draft 1.1 ‘airdrop’ tab.

[Giantkin]

A)The community delegates authority to the Archeo development team to determine the final specifications within each bucket described above. However, any changes to the buckets would require an additional proposal.

Wordage wise, im not sure if this means the dev team has say so, or proposal vote has say so? (or both?)

[Giantkin]

Wordage wise, im not sure if this means the dev team has say so, or proposal vote has say so? (or both?)

[con5cience]

Can we get some clarification around the decision-making behind the airdrop allocations? Is it just to create a market with people who are already invested in the Shapeshift ecosystem in some capacity? I guess I don’t really get where the value-add is with handing buckets of this token to Liquidity Providers or Cosmos Zone Delegators or even FOX token holders really – At least with Validator operators there’s an established context of those individuals being people who already operate blockchain infrastructure, so there is a higher chance of enticing those individuals to also stand up Unchained nodes.

Thanks for any insight.

[jonisjon]

hey @giantkin, thanks for summarizing some of this discussion from discord and posting here. You ended up posting a few comments so I will to reply to each in kind and give as much clarity as I can.

“1. Maybe a tighter defined aspect around the Arkeo workstream determining the decisions in each bucket. I think (my opinion) is that the naysayers are thinking the DEV’s will have full control of such. and not the Chain token voting holders. (which would be everyone in the ‘airdrop’ initially)”

Yea, so the idea here is that whatever is approved by governance cannot be changed without further governance discussion and approval. This includes all of the important aspects around the high level % buckets of the initial distribution and airdrop. The parts, as currently written, that could be changed by the WS are meant to be limited to specific items that still need to be figured out and are currently defined in the airdrop spec. I see you noted this later so will discuss that separately.

1. “Now that i say that, i realize the WS is specially pointed as being in control. maybe we set out the exact 'guidelines' that were mentioned for those decisions?

1. Each 'bucket' is separate, would the Arkeo WS have control of items inside of Each bucket? and what are the choices that they would be able to make. (and whats the stopping point of such)
2. make it more clear for me at least.

1. ofc, the only one that has any variables that are visible, is the airdrop bucket.

1. in the airdrop tab, notes section, the items are listed that the WS would have to determine yet. but in the proposal, they are not listed. Maybe list them as the restricted items that can be determined via the WS?

1. --hoping im not way off here “

The limited control of the workstream is meant to be around specific things that need to be determined within each bucket. As you rightly note this is currently described in the airdrop notes:

So this includes:

• Whether or not we add actions to receive the airdrop (similar to osmosis and some others that launched), this could be a great way to increase engagement and make sure the airdrop goes to engaged participants, but it will take some engineering effort to do this and we thought it better to put off this decision until closer to launch.
• Whether or not airdrop will be immediately claimable or some portion will vest. This is an engineering detail and will take some effort to implement, so again seemed to make more sense to decide once we are further down the field, any such vesting would be applied equally to all airdrop participants (and the dev allocation will have the same vesting terms).
• Amount of time of airdrop being claimable/decay before being returned to the community treasury, again this is better decided once we have some of these other aspects figured out on the technical side and would be applied equally to everyone.
• If you qualify for multiple buckets should your rewards get multiplied, this will take some technical time to figure out so we figured better to decide later via the WS but would of course be applied equally again across everyone.
• Finally, this one I notice is not in the notes, but how exactly to technically apply the rolling snapshot described in the proposal will take some engineering effort and thus we figured best to just let the WS implement that.

These are the “only” things as currently written the WS would have any power over, the buckets could not be changed nor the allocations without further governance approval.

[jonisjon]

I think my post here covers this pretty well now: https://forum.shapeshift.com/landing?method=share&thread=ideation-post-scp-111-shapeshift-foxchain-proposal-phase-2-41210&refer_id=28625&post=1951328

[jonisjon]

So my understanding of this (and happy to take wording suggestions to make it clearer) is that only the things specifically described in the notes can be decided by the WS (which are primarily meant to be technical details, nothing high level which would affect the buckets or distribution). These are pretty nuanced technically decisions that will need to be made so it still seems better to leave that in the hands of the WS, but of course nothing can be violated around the actual distribution or bucket methodology the community approves as part of this.