Dottyland: Jan-Feb’23 update

A quick update on what we’ve been up to in early 2023. The purpose of this update is less philosophical visioning (we do those too) and more holding ourselves accountable and recording our progress transparently for the benefit of our team, our stakeholders and most importantly, our very involved closed group of beta who are selflessly sharing their insights, feedback and time.

For context, this is an early step of Stage 1 of our long term plan which is establishing strong core architecture for impact data sourcing, aggregation and output into a single sovereign impact identity and testing its utility propositions and single-partnership/collaboration based value generation.

(Stage 2 will be establishment of sovereign Impact Selves data and applications network and multi-partnership value flywheel with Dottyland as enabler of flywheel).

It’s a long’ish read, thematically splitting into four:

1. Infrastructure/architecture
2. UX
3. Data Sources and Impact Score
4. Utility and collaboration

1. Infrastructure/ architecture

We ended 2022 with a very raw pre-beta architecture, a critical review and a concrete update plan, to solidify the foundation for future growth and usability.

• From monolith to microservices. As part of our infrastructure and architecture review, we decided to switch from a monolithic architecture to microservices. This allows us to break down our applications into smaller, more manageable components, which can be developed, tested, and deployed independently. This also makes it easier to scale our applications and improve performance, as we can allocate resources more efficiently and effectively.
• Private keys management. Not surprisingly, of the most dangerous weak points of dApps that need to sign transactions in the backend is the management of keys. If an attacker infiltrates the system and steals the private key, they can cause significant damage. To avoid such a situation, we started using the OpenZeppelin Relay, which offloads the key management responsibility and notably secures our system.
• Sources management. Although the proof of concept was functioning well with the couple of sources it was designed for, we aimed to create a system that allowed for easy and low-cost addition of sources. Another important requirement was to decentralise and democratise the Impact Self. We want to enable third parties to freely manage and add their own sources. To achieve this, we restructured the way sources are retrieved, analysed, and written on-chain. This restructuring considerably improved the system’s scalability, cost and speed.
• New scoring system. Designing a scoring system that allows multiple platforms to participate together, that is future-proof (or as future-proof as it can be), that can be written and read on-chain, and takes into account multiple different streams is not an easy task. We have been putting quite a bit of effort into it and came up with the concept of “writers“. A writer manages multiple sources and defines their score for a user. This will allow greater participation in the Impact Self scoring in the near future and already improved the way we present data to the user. Being something so complex and inherently tied to Dottyland, we are treating the scoring system as something that will organically grow alongside the platform, so expect new and exciting changes in the future!
• Solid testing. We devote considerable effort to continuously improving our testing approach for the application, user interface, and smart contracts. To ensure the reliability of critical software, we test frequently and comprehensively. To maximize test coverage, we have developed a suite of unit and integration tests, as well as a test environment for experimenting with new features before deploying them to the live site. This test environment is an exact replica of the live site, encompassing front-end, back-end, and contract deployment across various testnets.

2. UX/UI

With the first early testers, it became apparent, that there were several barriers preventing users from claiming their Impact Selves.

• Design. After shortening and sharpening onboarding flow (aka combining views), we found that users remained in Ground Control (aka regen dashboard) view without clicking the Claim link. To them the dashboard seemed like the end destination whereas for us, it is the individual’s overview of the data connected and sourced for their Impact Self. The quick solution for this was a UI, contrast + H1–3 reset on page + component spacing.
• Faucet. Users did not proceed because they didn’t hold MATIC in their wallet. We’ve added a faucet to prevent lack of MATIC from being the reason to not claim an Impact Self.
• Mobile. It wasn’t a priority for us at the start with everything else going on but it was certainly a realization that at this stage we’re getting most testers onboarded while in active conversation with them either over a call or irl. Frequently, their instinct is to go into the flow via mobile. The UX/UI adjustment was quick (though future improvements are already spelling themselves out) but the biggest hurdles were mainly related to Metamask responsiveness.
• Multi-wallet. Users held indicators of different positive impact actions in different wallets. A single wallet input therefore prevented them from reaching their highest possible impact score. Multi-wallet connect solved this (within a 3-wallet range, for now).
• Impact Self visual upgrade. When launching the POC end of ’22, we did so with a generic placeholder image for the Impact Self. The core of the Impact Self will always be the individual behavioural data which forms our digital impact identity but giving it a visual signifier makes it more tangible. (We hadn’t even communicated our thoughts on this when it was also already brought up by test users). Working with a significant number of assets created by Kimverlyn Lim, we launched an extensive collection of 3d art (refraining from hyperrealism and adding a hint of collage — but this is a personal story for another time for those into such discussions), featuring a narrative around protecting and fighting alongside Mother Earth.
  The Impact Self is an SBT, it cannot be sold or transferred to anyone (apart from burn address) its’ value is rooted in its owners accumulative climate-positive action behavioural data. Therefore, although the default of external marketplaces is to assign perceived value based on rarity traits etc, the organically existing rarity levels related to traits featured in the art, are only for the joy of the identity owner and hold no market value.
• Data overview preview. We are actively and intentionally on a path to make complete impact data ownership and control possible for the owner of the associated Impact Self. (In other words, in the long run, we have no intention of being the owners of the data, rather just facilitators/enablers of its utilisation). Getting to that state of ideal is essentially our core journey and what we measure most infrastructure choices against internally. A seemingly small but particularly important step on this journey was making the individual aggregated data more immediately accessible for the owner of the Impact Self. Not packaging it away with a need to download at some later date. But rather, treating it as part of the user experience in the same environment.

Spotted: Impact Self #26

3. Data expansion and Impact Score changes

• Data Sources. The POC launched at the end of ’22 was based on on-chain offsetting data as impact score input. The reason for it was, at the time, it was the lowest hanging fruit to start testing a scoring model which includes more than categorical variables. No need to go into the limitations of carbon offsetting here but naturally, our goal was to start expanding data input sources so as to reflect more actions/activities of the community the first version of the Impact Self version caters to. By now, we have established 12 on-chain and our first off-chain source data connections.
• Score build ‘starter kit’. We’re building around the hypothesis that alongside the ‘quantity’ of climate-positive action we need diversity of such actions in individual behaviour. Therefore, with the long view in mind, the user enabling the connection to a specific data source in the dapp (even with behavioural activity inside that source being 0 — i.e. for example, you’ve never offset NCT) in itself holds impact data value. As such, each connected source is currently reflected in a point added to the score. (Currently because we are actively testing and improving the scoring formula/model and it is highly likely the values will change inside of it during this process.)
• Adaptive modelling and sandbox. Since there are no blueprints for this type of individual climate-positive behaviour scoring models (at least not ones our environmental advisers were able to point to), we started from scratch. The model itself is one that will be getting a whole lot more attention in the coming months as we expand into different behavioural verticals. So we’ve implemented a modelling sandbox in the background. In the short term, this is a format for reviewing the effects new sources added have on the weighted adaptive model. In the long term, this will enable previews for different models’ effects on an individual’s impact score (so that the individual Impact Self holder may one day also pick and choose which of their activities feed into the score and which as so-to-call validation/proof stamps for example).

Spotted at a ReFi black site: Impact Self #9

4. Collaborations.

We ended ’22 with the assumption of delivering an intelligent virtue signalling badge for one of the web3 social solutions in the early days of ’23 (and yes, the indications for receptiveness was there). Only to find out that in the new light of things perhaps we were too early still (to be honest, what we had to show was indeed extremely raw at the time). Honesty is good.

Looking at behaviour as multi-input data through an impact lens is still a hugely valuable foundation for signalling so we’ll be returning to this more actively in the coming months. In the meantime, our first collaborations ended up coming about more organically.

• Spirals Protocol. We looked at how could we build exponential impact into the act of claiming an Impact Self and built in default staking on Spirals Protocol each time an Impact Self is minted. Spirals Protocol further invests all yield into climate projects. This holds no expense for the user (principal is from Dottyland’s funds) whilst owning an Impact Self itself can now contribute as a data point into the impact score.
• Blu3. With an incredibly strong alignment in personal values combined with our own belief that supporting DEI in tech and impact solutions is key in achieving results in climate solutions also, we wanted to see whether there’d be a way for us to support Blu3 utilising what we’ve got. So the Blu3 Impact Self was born. With three variations signalling hacker, member and core team statuses, the custom solution provides Blu3 community an impact identity with a visual identifier. We are also exploring how to integrate Blu3 into the impact score for the members.

Thank you for taking the time to read this and please do get in touch to join as a beta-tester!

Kärri