|Wallet||Stable Coins||Hours||Rate / Hr.||Period|
I’m a data scientist/developer with experience in academic research and entrepreneurial ventures. I studied Software Engineering (dropout), then Cognitive Science (Spe AI). Worked as a Data Scientist / Engineer for Santander Bank, Inditex, Mercedez Benz, Saiki (AI startup).
Besides the title, I took care of tasks outside of my role scope, having experience with a big chunk of the data cycle. Also, I have been doing Data for dOrg, which includes creating a quick internal dashboard, KPI, insights, R&D, viz., and hypothesis testing.
I recently graduated from Chainshot Ethereum Bootcamp and helped with some issues on Defiwrapper.
We would start the Polywrap data initiative to use data to ensure that we focus on areas that provide better user experiences. We will use data to help us answer important questions in all areas of our project.
Internal Ops Metrics - These would be dashboards for Snapshot, Discourse Github activity, DAO Discord activity, governance stats. For example, community growth dashboard (Twitter, discord, GitHub stars, npm downloads, etc.), or code velocity on the different repos (how many commits, new branches, lines added/removed)
We could also add ETL processes and automation if needed.
Despite the uncertainty of the final result and all steps, we will find three keypoints or deliverables:
1- Roadmap/Doc of all the feature-characteristics-scope of the final result. Mainly in this step, the time will be speed on the study and gathering the opinion of the needed - required metrics for answering - measure the desired sectors of this project.
2- Development of the code needed for the creation of all metrics-KPI-measurements. Code required for pulling, manipulating, and creating the required metrics or features. Needed despair of what solution we choose.
3- Development / Deployment of the required system / API / Dash depending on what we choose. Building what is necessary for delivering the final product would cover all our features created in phase 2.
This 3 step or derivable flow would be replicable for both phases (Internal Ops Metrics & Protocol Metrics). Obviously, I wouldn’t create 2 APIs. Just to make it clear. In that case, we would just replicate steps 1 and 2.
- Should we save the data, have it indexed, and create a historical log for future analysis or predictions?
Yes, we could have these stored in a database like MongoAtlas.
- What questions do we want to answer with data?
- Overall interest
- Number of developers using the protocol
- DAO Activity and governance
- Status of the treasury
- WRAP Token stats
- Landing page, docs, and handbook engagement
- Decentralisation (Maybe measured with gini coeficient)
- What Operational data points should we consider logging now?
Github: PRs, Pushes, Commits, Favorites, Forks, number of contributor accounts, new branches, lines added/removed. (should be possible to create without a secret API key)
npm: Number of package downloads
Discord: users, messages per day, (some of this is already calculated by discord, but it’s only available to admins, not all members)
Twitter: followers, likes, retweets, replies, aggregated interactions (The twitter analytics )
Snapshot: Proposals sent, voter participation, most active voters
Token: Tokens minted, holder distribution, tokens minted last month, graph of token distribution over time (Some of this can be derived from the DefiSDK once it has the “account resolver working”)
Treasury: Funds in multisig, recent transactions, 30 day treasury change, expense categories (legal, contributor payments, etc.)
Events: List of public upcoming calendar events
- Do you want everyone to be able to pull this data?
Not sure. Depends on the data we have described above, these data points are fairly public, so all of it can be public from the start, and become priviledged on an case-by-case bases.
- Do we want to have a dashboard?
Yes. The frontend development of this could be done in a separate proposal by another contributor.
- Is that going to be a private or public dashboard?
Initially, we could have a single dashboard targetted to one specific audience (decided in the question above)
- What about the 2nd phase about protocol metrics?
We can suggest the path forward for this, but not directly develop these metrics because a lot of this is not developable rightnow.
However, the data we gather on the process developed on this phase should be compatible with the infra built on phase 1. Phase 2 can be done in the future in a separate proposal.