These Kin Rewards Engine Valid Transaction Guidelines (the "KRE Transaction Guidelines") are supplemental and subject to the Kin Foundation Developer Guidelines (the "Guidelines"). Unless otherwise defined below, terms defined in the Guidelines have the same meaning when used in these KRE Transaction Guidelines.
Who is this guideline for?
This guideline outlines the minimum requirements for a Developer to receive a payout from the KRE. [link to medium articles that explain context].
- Definitions
The following definitions apply in this document:
| Term | Definition |
|---|---|
| "Earn Transaction" | a Transaction originated by you to a User within your Application; |
| "Passive Subscription Payment" | a Transaction made by a User to pay for a Subscription where the User is not required to actively initiate the Transaction pursuant to Section 9.7; |
| "P2P Transaction" | a Transaction between one User and another User within your Application; |
| "Prohibited Transaction" | any Transaction described in 'Section D – Prohibited Transactions'; |
| "Spend Transaction" | a P2P Transaction or a U2D Transaction; |
| "Subscription" | an arrangement made between a User and (a) you; or (b) with another User within your Application, to receive something by advance payment; |
| "Transaction" | an instance where KIN is transferred from one wallet to another wallet within the Kin Ecosystem; |
| "U2D Transaction" | a Transaction originated from a User to you within your Application; |
| "User" | an End-User that is a natural person with a single wallet in your Application; |
| "you", "your" | the Developer, and where the context requires, their Application. |
- Eligibility to receive a KRE Payout
To receive a payout from the KRE:
2.1 you must satisfy in our discretion all of the Minimum Requirements as set out in Section A and all of the applicable Specific Transaction Requirements as set out in Section B; and
2.2 your Application must not contain any Prohibited Transaction as set out in Section D.
SECTION A - MINIMUM REQUIREMENTS
- Awareness and control
3.1. The sending party of a Transaction must have control over the initiation of that Transaction unless it is Passive Subscription Payment.
3.2. Both parties to a Transaction must be aware of the Transaction at the time it occurs.
- Developer to be in compliance
You must not in our reasonable opinion be:
4.1 in breach of the Guidelines and/or these KRE Transaction Guidelines; or
4.2 in breach of any app store policy that your Application is subject to the extent we consider this breach to be or likely to be detrimental to the Kin Ecosystem.
- Publicly known entity
Your Application must be publicly available.
- Usability
For each Transaction initiated by a User, the KIN logo must be present on the action/button.
SECTION B - SPECIFIC TRANSACTION REQUIREMENTS
- Spend Transactions
7.1. Each Spend Transaction must:
(a) include clear communication to the User of the amount of the Spend Transaction;
(b) include clear communication to the User of what they will receive in return for their KIN;
(c) be initiated by a unique action undertaken by the User;
(d) include a clear confirmation to the User once the Spend Transaction has occurred / payment was made;
(e) include the ability to acknowledge and dismiss the confirmation above. Once acknowledged or dismissed, there should be no need to re-communicate the information to the User.
7.2 If the amount of the Spend Transaction is less than or equal to 100 KIN then the Transaction may be initiated by a single tap by the User (such as the User tapping 'like' or a 'heart', or tapping 'ok') provided that you have firstly informed the User the cost of undertaking the relevant action that initiates the Spend Transaction (e.g. by a tutorial, button confirmation or notification).
7.3 If the amount of the Spend Transaction is greater than 100 KIN, then:
(a) the amount of KIN must be clearly stated on or near the action/button that will initiate the Spend Transaction;
(b) the Spend Transaction must have a flow with a minimum of two taps by the User (e.g. undo, confirm, input amount or amount selection); and
(c) a button must be included requiring the User to confirm/acknowledge the initiation of the Spend Transaction.
7.4. A Spend Transaction must not be a Prohibited Transaction.
- Earn Transactions
8.1. Each Earn Transaction, regardless of the amount transacted, must include:
(a) clear communication to the User of the amount of the Transaction; and
(b) the Transaction is generated by a unique action undertaken by the User.
8.2. An Earn Transaction must not be a Prohibited Transaction.
- Subscription Transactions
9.1. A User may enter into a Subscription with:
(a) your Application (and each Subscription payment by the User to the Application will be treated as a U2D Transaction); or
(b) another User, for example a specific content creator (and each Subscription payment by the User to the other User will be treated as a P2P Transaction).
9.2. The entering into a Subscription by a User must be clear and explicit to the User and it must contain the following:
(a) the amount of KIN to be charged in total for the length of the Subscription period;
(b) the length of the Subscription period;
(c) what the User is to receive as a subscriber;
(d) a confirm/acknowledgement button; and
(e) information on how to unsubscribe.
9.3. The cost of the Subscription must be set to a fixed amount for the period of the Subscription.
9.4. The length of a Subscription period may only be monthly or annually. The length of a Subscription must not exceed one year.
9.5 For each Subscription period set out in Column 1 in the table below (a) the User's payment obligations for that Subscription must correspond to Column 2; and (b) unless the Subscription is renewed by the User, the maximum length of the Subscription must not exceed the numbers of days prescribed in Column 3 (if any).
| Column 1 (Subscription Period) | Column 2 (How does a User pay for the Subscription) | Column 3 Maximum length of Subscription (unless User elects to renew) |
|---|---|---|
| Monthly | The User pays once per calendar month at fixed intervals. | 365 days |
| Annually | The Users pays once per year. | No maximum limit |
9.6. If a User is offered a renewal of their Subscription, the renewal must be offered around the time their current Subscription is due to expire. The offer to renew must be clear and explicit to the User and be in accordance with this Section 9.
9.7. Other than the initial payment of the Subscription cost, subsequent payments for the same Subscription during the Subscription Period may be Passive Subscription Payments. A Passive Subscription Payment does not require the User to actively initiate the Transaction rather it may occur automatically. You still must ensure that the User is made aware that a Passive Subscription Payment was made by the User in connection with the Subscription at the time the payment is made.
9.8 A Passive Subscription Payment will be counted as a U2D Transaction or a P2P Transaction, as the case may be, provided that the frequency of such payments does not exceed Column 2 in Section 9.5 for the relevant Subscription period.
9.9 A User must be able to unsubscribe from a Subscription at any time without further obligation to pay.
SECTION C - PROCESS FOR HANDLING VIOLATIONS
- Developer to be excluded from KRE payments
10.1. If we reasonably believe that your Application is in breach of these KRE Transaction Guidelines:
(a) we will provide notice to you. We may additionally provide steps you need to take to remedy the breach however we are not obliged to do so; and
(b) we may exclude your Application from receiving any payout from the KRE. If your Application is excluded, the payout available from the KRE will be distributed rateably amongst the remaining participants of the KRE who remain eligible.
10.2 Repeated or an egregious breach of these KRE Transaction Guidelines may result in your temporary or permanent ban from the KRE.
10.3 Any temporary ban may be instated, lifted or reinstated at our sole discretion and subject to any conditions we see fit.
- Remedying a breach
If you have breached these KRE Transaction Guidelines:
11.1 we may permit you to remedy the breach where it is capable of remedy by providing an updated version of the Application in each app store it is available evidencing that the Application is no longer in breach of these KRE Transaction Guidelines, however we are not obliged to consider remedial action;
11.2 any payouts from the KRE the Application may have received during the period the Application was excluded from payouts from the KRE will not be re-credited.
SECTION D – PROHIBITED TRANSACTIONS
The following are Prohibited Transactions for the purposes of the KRE. An Application which contains any Prohibited Transaction will be excluded from payouts from the KRE.
- A Transaction or series of Transactions where:
12.1 you have credited a User an amount of KIN, only to force the User to pay all or part of the credited KIN back to you; or
12.2 the purpose of the Transaction or series of Transactions appears, in our view, designed to manufacture the number of Spend Transactions on behalf of Users within your Application.