2 Suggested Additions to Self-Assessment Questions

[tonyjacob]

Suggestion 1 - In app availability of blockchain transaction data

One aspect that I find presently lacking within Kin apps is their lack of providing their users with access to contextual blockchain data provided by 3rd party solutions such as Kinscan, Solscan, Solana.fm etc in relation to their spends or earns in real time or for historical purposes. Based on the style of other self-assessment questions, perhaps the question could be framed similarly and in an objective manner.

Question:

Does your app provide your users with access to Kin transaction links to 3rd party block explorers such as Kinscan, Solscan, Solana.fm. explorer.solana or other Kin explorers of your choice for in-app spend, earn, peer-to-peer, staking rewards or other transaction types?

I think that this is important due to the following reasons:

1. Greater control over more valuable transactions & larger balances in app

As the KRE 4.0 incentivizes greater spends by users through the introduction of the minimum spend threshold (ex. rise from 1 Kin to 833 Kin per spend in order to count towards KRE rewards), maximization of the median user balance and user spends, integration of buy-modules and all of which possibly leads to users holding larger and more valuable Kin balances within apps, the need by users to have access to real time and historical blockchain data about their in-app transactions and holdings will become more critical and important.

As an example, as apps move from getting users to spend 1 or 10 Kin (as in many cases today) towards thousands of Kin per spend, and as Kin potentially grows in value over the duration of the KRE 4.0 lifespan and beyond, I think that users should have better control of the Kin that they spend and own in app which includes having access to valuable transaction data on the blockchain.

2. Provide users with increased transaction visibility & transparency

From what I've observed with past ecosystem apps and in some cases a few present apps, due to the lack of visibility of in-app transactions, app users are entirely reliant on the developer to know when the transaction has either been sent or received by watching their wallet balance move up or down. This seems to be the only way to monitor balance changes in the app for many users. App users could benefit by having direct access to blockchain data from a 3rd party provider that provides them with information about their transaction.

3. Increased Trust

In app Kin users should know with certainty that the Kin that they're using is the real Kin and not a database point system masquerading as Kin. I think that in-app access to real time or historical transactions via a 3rd party blockchain data provider can help with this.

Suggestion 2 - Improved user experience of Kin in app

I noticed that the current list of self assessment questions in many ways sets Kin user experience expectations such as the ability to view and copy the user's Kin public wallet address, ability to export their private address, ability to import or connect an external Kin wallet etc. While many of the apps of today would meet these expectations on a per feature/capability basis, I’ve noticed that the overall Kin user experience is rather disjointed and in many cases hidden away under one or several layers of in app menu settings thus reducing the discoverability of Kin in app.

Perhaps there might be a need here to help make available a reference design standard for developers to help improve the discoverability and unification of the overall Kin user experience within each of the Kin ecosystem apps so that an objective self-assessment question could be developed. The reference design standard that comes to mind here is the popular standard utilized in most mobile wallet apps, i.e. bottom navigation bar of mobile app having a wallet navigation button that navigates the user to where the majority of the existing Kin user experience is housed and contained such as ability to view and copy the user's Kin public wallet address, ability to export their private address, ability to import or connect an external Kin wallet, ability to deposit Kin, introduction to Kin, tutorial for using Kin and Kin related features, fiat-to-crypto payment solution, transaction history and linking to 3rd party blockchain data etc.

I am mindful of the fact that any reference design standard or self-assessment question that is developed to improve the underlying Kin user experience should strike a careful balance in order to incentivize developers to improve their Kin UX while also not being overly prescriptive with the design standard which could potentially inhibit developers from adopting Kin or its continued use within their apps. Perhaps an additional bonus reward could be offered to developers that doesn’t affect their normal expected payment if for whatever reason being prescriptive is the only way to objectively measure improvements on this front.

If an objective self-assessment question could be developed that could help incentivize this behavior without the need for a reference design standard, then this would naturally help to achieve the user experience result sooner.

Interested in feedback.

[hann228]

Hi Tony
These are both good arguments which you have explained clearly.
For KRE 4 the published proposal is already asking developers to make several significant changes to both their current mode of operation and use cases so we are conscious that - after the feedback we received during our extensive consultation process on this proposal with the ecosystem - that we did not want to set the bar for quality factors to be too onerous as ultimately this would make adding Kin to an app be unattractive. The idea was at the inception of kre 4 to try to strike the balance in this space to incentivize developers to want to improve features which were ‘low hanging fruit’ and where we had observed that many sit on the fence about their inclusion.

We did intend that the quality factor questions may change over time – so I have added this proposal to our KRE review stream, and we will soundboard it off the developer community during our next consultation process. We will have more to say about it at a later point in time.

[tonyjacob]

Thanks for the consideration. I look forward to future updates on the quality factors.