Ted-Livingston on Definition Spends & Earns

[Freedom-kin]

Hi Ted, I've taken the liberty of copying your comments into this discussion.

ted-livingston
3 days ago
Hey Freedom. I appreciate you taking the time to put this proposal together. It gets me excited to see you and others leaning in on this, as I agree the KRE is the most important part of Kin. I hope we can all work together to explore these ideas and find the best solutions.

I have a few thoughts on your proposal, but I wonder if it might be helpful to take them one at a time. My goal isn’t to be pedantic, but to keep the discussion focused so that we aren’t trying to tackle multiple topics at once.

Perhaps my first question is around how you define “earn” and “spend”.

For example, is a buy through an in app buy module an earn? Is a deposit from an exchange?

For a spend, is it anything that lowers a user’s balance? If not does a user to user transaction within an app count? Does a withdraw to an exchange? What about a transfer from one app to another?

I think these definitions are important to both reduce gaming and create the right incentives.

For example, one way how I see gaming could potentially occur:

1. Developer buys 1000 Kin on an exchange
2. Developer deposits 1000 Kin from the exchange into “user_account1”, which they control
3. user_account1 tips 1000 Kin to user_account2, another account controlled by the developer
4. user_account2 withdraws 1000 Kin to an exchange, where the developer sells it

In this scenario it seems like user_account1 might look like it had a net spend of 1,000 Kin, resulting in a 300 Kin bonus for the developer, even though they are just moving money around programmatically. Perhaps even simpler, instead of tipping user_account2, the developer could perhaps just have user_account1 buy a digital good from the app. There likely wouldn't be any sales tax, as just because an app tells the KRE it made a sale, it seems they could tell their accountant they were just moving money around, which I don't think would be breaking any accounting rules.

What are your thoughts on this and how your proposal might protect against it?

[Freedom-kin]

Thank you for responding, Ted.
Those are some good questions.

Your first question is How to define EARN and SPEND.

Users can only do 4 things with their user wallets.

1. They can SPEND Kin in app.
2. They can EARN Kin in app.
3. They can withdraw Kin
4. They can deposit Kin

We also know the wallet address of the app.
If not, we should register one address per app for all activity, SPENDS and EARNS.
It is mandatory for all transactions to go through that address.

What counts are numbers 1 + 2.

A SPEND always lowers the user balance.
An EARN always raises the balance..

Transactions (tx) seen from user point of view:

IF  tx is between user wallet and app THEN   
      IF tx is negative THEN tx is a SPEND   
          ELSE  tx is an EARN   
      end if   
end if
           
IF tx is NOT between user wallet and app THEN
       IF tx is negative THEN  tx is a WITHDRAWAL
            ELSE  tx is a DEPOSIT
       end if
end if

A user to user tx falls under 3 and 4.
It basically is a withdrawal from user A and a deposit for user B.

This way we can see the difference between real SPENDS / EARNS and all other transactions.
What we can NOT see is the difference between a user to user tx and a withdrawal/deposit.

That means that if we pull P2P tx into the KRE you open the door for massive gaming.
Exactly that happened in earlier iterations of the KRE.

The only way to stop gaming is to just reward SPENDS minus EARNS.
However, some of those transactions ( 3 + 4 ) are very important for the community, even necessary.
That's why I propose a second fund for those apps.

Is a buy through an in app buy module an EARN?
No it is not.
I don't see any angle on how you could EARN with your own money.
I pay with $$ and get Kin. It's more like a deposit to my own user wallet.
It can become a SPEND if I buy something with that same Kin in app..

Is a deposit from an exchange an EARN?
No, it falls under number 4

Is a SPEND anything that lowers the user balance?
No, just the numbers 1 an 2 from the list are SPENDS/EARNS.

Is a User to User transaction a SPEND?
No, they fall under 3 and 4
Allowing them under the KRE would open the door to massive gaming.

Is a withdrawal to an exchange a SPEND?
No, it falls under number 3.

Is a tranfer from one app to another a SPEND?
No, it falls under number 3 and 4.
It's in fact the same user that withdraws and deposits on his own accounts.
Nothing to do with spending.

Your example of potential gaming

1. Developer buys 1000 Kin on an exchange
   okay, no problem
2. Deposits this into úser_account1, which he controls
   This would be a number 4 on the list.
3. User_account1 tips 1000 Kin to user_account2
   This would be a nr 3 for user1 and a nr 4 for user2
4. User_account2 withdraws 1000 Kin to exchange
   This would be a nr 3 on the list.

Not one time a number 1 or 2 ( SPEND or EARN ) was made.
They can do this as often they want, it has no effect on their KRE payout.

The next is your variation that instead of tipping in step 3, something is bought in app.
That would be the first SPEND in this sequence of steps.
Now the registered wallet address of the app contains the 1000 Kin.
Step 4 is no longer an option.
The 1000 Kin now count as a SPEND and is rewarded with KRE.

There likely wouldn't be any sales tax, as just because an app tells the KRE it made a sale, it seems they could tell their accountant they were just moving money around, which I don't think would be breaking any accounting rules.

We don't have to rely on what a developer passes on to the KRE. We don't need a memo field. Everything is automatically arranged from the transactions on the blockchain. The memo field can again be used for what it is intended for... a memo.

..................

What you get with this system is that you only reward the actual Economic Activity.
Economic Activity is the exchange of goods or services for Kin.
We reward the actual FLOW of KIN through the economy.

That's why we need a 2nd fund for apps that are very important, but don't have Economic Activity.
e.g. tipping is important, but it's no exchange of goods or services.
It doesn't add economical value to the economy.

A buy module is very very important, but it in itself is no exchange of goods or services. It is a tool.
I can buy Kin with it in app and leave it in my user wallet.
It is in fact a deposit to my user wallet.
Only until I buy something with that Kin it becomes an Economic Activity.

Opening up the KRE for buy modules would mean rewarding deposits....and that, as shown above, opens the door for gaming.

So the only logical thing to do is to make a 2nd fund and determine on a case by case base whether an app qualifies for it.

In case of CODE it is very simple.
You already indicated that you would burn all rewarded Kin that exceeds the real costs. That means that if you show what those real costs are, that 2nd fund can award you that amount periodically.

However, we don't need e.g. 20 different buy modules.
We can say it's enough. We will not spend more public money on the development of buy modules. If you want to make one...fine, but at your own cost.

I admit it all sounds very strict, but for now it is necessary.
We will have to build an economy from scratch. We have inflation from here to Tokyo and hardly any economic activity. We simply cannot afford to spend money on things that don't go to the heart of the economy. Later, when we have a running economy, we can get a little easier.

[Freedom-kin]

Good point. This possibility has been discussed with the KF before, I called it the carousel. It's like taking money out of your own cash register, buying another item and repeating this over and over. No entrepreneur would do such a stupid thing.

KRE 4.0 rewards with 30%.
If you have 1000 SPENDS you get 300 Kin.
Total fiscal profit is 1300 Kin.
Tax rates differ per country, but lets say VAT = 20% and income tax is 35%

1300 / 120 * 20 = 216 (VAT)
(1300 - 216) * 35% = 379 (TAX)

Total tax 216 + 379 = 595
Net income 1300 – 595 = 705 Kin

But now you tripple your net turnover by gaming your spends.
3 x 1000 = 3000 turnover
30% = 900 KRE
Total fiscal profit 3900

3900 / 120 * 20 = 650 (VAT)
(3900 – 650)) * 35% = 1137 (TAX)

Total tax 650 + 1137 = 1787

However, you didn't really got 3000 turnover, that was fake.
You had just 1000 + 900 KRE = 1900 gross profit.

Net income is now
1900 – 1787 = 113 ...you now actually make less than without gaming

What prevents a developer from simply not reporting this turnover to the tax authorities?

We must make our 'weakness' our strength.
The KRE is unique in cryptoland. Through this system we know exactly how much turnover a developer has made and how much KRE reward he has received.

It should not be difficult to produce an annual overview of this data.
We can submit this overview annually to the developer for his declaration.
In addition, the conditions of the KRE will state that this data will be kept, for example, for 5 years and made available to governments if requested.

It's nice when governments keep everyone honest.

It has more advantages.
What if governments accuse the KF of organizing a huge black market?

Think about it.
At the moment, the KF finances almost the entire income of developers through the KRE.

If those developers declare too little on their tax returns, and the KF paid them in full, who do you think they will turn to? Who made all this possible? They just have to come up with the accusation...how is the KF going to defend itself?

If you lived here in the Netherlands, the judge could rule that all those developers are bogus self-employed. The judge may rule that they are deemed to be in paid employment of the KF because this corresponds more with reality.

Each country will judge this in its own way, but it gives you an idea what I mean.
All governments want is their share of the profit, the tax.

With KRE 4.0 we reward with 30%, which means that they also generate their own income, which is a characteristic of self-employed entrepreneurs. In addition, if we show that we work with governments in every possible way, by having the revenue data available, lawyers will be very grateful to you later.

Again, this is a unique feature of the KRE. I am curious how other cryptos will solve this problem with governments.

[ted-livingston]

Hi Freedom. I agree that we want to be onside with governments, and that we should aspire to work with them to promote the adoption and growth of this amazing technology. My concern is on the accounting side.

Just because something “looks like” a sale to the KRE, I’m not sure it means a developer would have to book it as such when calculating their sales tax. I’m not an accountant so it would be interesting to get one to weigh in, but I would assume a developer could book this as some sort of “promotion” or “investment” and not an actual sale, because the truth is, it wouldn’t be a sale.

On the income tax side, this only comes into play if the developer produces a net profit. It seems like a developer could use their fraudulent KRE income to hire more developers or buy more ads and never pay income tax on it.

Given these two things it feels like it would be pretty easy for a malicious developer to game a spend based KRE, without needing to break any laws to do so.

What do you think?

[Freedom-kin]

Hi Ted,
I see your point and I agree.
So let's forget about the help of tax collectors.
We need to be able to manage it within the KRE system.

First I would like to mention that there will probabelly be no system that is 100% not gamable.
Even the fiat economies we live in have that problem.
There is a lot of 'black money' in circulation and yet we have a running economy.
The only thing we can do is make it as hard as possible to game.
Even the current KRE is highly gamed.
What we have now is a system that hinders the flow of kin AND is gamable.

So what I'm looking for is a system that at least promotes Economic Activity by making Kin flow through the system AND is least gameble.

The problem you see is that Kin that is spent is withdrawn from the app's wallet by the dev and deposited to a user account that is under his control and than spends it again in the app, thus producing more and more SPENDS without deductable EARNS.

We can make this carousel a lot harder by not deducting the EARNS from the SPENDS, but deducting everything that goes OUT of the apps registered wallet.

There are only two things going out of the wallet...the EARNS for the users and the withdrawals from the developer.
At first glance it is strange to deduct withdrawals from the SPENDS. Keep in mind, though, that this is a daily calculation and withdrawals may be only once in several weeks or even less.
All other days only EARNS will leave the wallet and will be deducted.
That means that on the day you withdraw, you probably won't get much KRE if it's more than that day's SPENDS. However, this is more than made up for by all the other days. It's a bit like the withdrawal fees that developers charge to users, which apparently nobody has any problem with.
Developers will postpone their withdrawals as long as possible to create as few withdrawal moments as possible...just like users do to minimize fees.

In any case, you break the carousel that you can repeat many times a day.
Is it perfectly waterproof? No, probably not.
I invite everyone to come up with suggestions to make this happen.

However, we do have a system that stimulates Economic Activity and that is always better than the current system.
I'm afraid we'll have to take a measure of gaming for granted. The CAP of 50MM on the daily payout prevents it from running out of control (we can lower that CAP if necessary).

As a side note, I'm still a proponent of making annual statements for both the developer and tax collectors...if only to protect the KF from legal problems. We may not count on their help, but every little bit helps. If developers want to game the system, they will have to do so very consciously, both with the KRE and in their accounting.

The advantage is that since we only reward spends, there are no other attack factors to worry about. And if there is someone who is gaming the system, it will not have any negative effect on other developers.

[ted-livingston]

Hi Freedom. I like how you are iterating through the options. To me that is how design is best done.

I think your proposal is a step in the right direction. The question I’m asking myself is “is it enough?”

For example it seems like with this latest version a developer would get no KRE the day they do the withdrawal, but would get it the rest of the days. So they couldn’t do the carousel every day, but it seems they could perhaps do it every other day. One option might be to increase the length of the calculation window (calculated weekly for example?) so that they could only do it every other week. That said I worry that they could just use larger amounts of Kin because the carousel would have “a guaranteed return on investment”.

What do you think?

Another thing I’m thinking about is if spends are the right thing to focus on generally, from a strategic point of view. I’m going to start a separate thread on this to keep it focused, but would appreciate your thoughts Freedom.

[Freedom-kin]

Surely there will be a way to game this. I will certainly continue to investigate how we can tackle this problem. Suppose we can make this system (almost) watertight, could this be a system that you would support?

From a strategic point of view, I think KRE must meet the following requirements:

• KRE must be sustainable in the long run
• KRE must be attractive to companies
• KRE must increase the value of the economy
• KRE should promote the flow of Kin through the economy.

[amiraliaaa]

Hello Freedom. I think undermining the huge risks that comes with the flaws and gaming potentials of the spend based KRE would be a huge mistake. Just relying on the government and tax authorities to deal with bad actors is not smart. You mentioned no smart entrepreneur would do such a thing but we all know that in the history of the KRE there have been developers who have gamed the formula. These developers had ways to avoid taxes so its safe to assume they would do the same thing with the new KRE formula specially now that the new spend-based formula makes is SUPER easy to be gamed.
I think the simpler that you make the formula, the easier it will be for the bad actors to game the system. Thats why I prefer KRE 3.1 or a variation of it with relying mostly on AU or AUB.

[Freedom-kin]

Hi Amiralia,

Let's asume for a moment that you are right and KRE 4.0 can be gamed.
I guesse you also agree that KRE 3.0 is very easy to game.
There are a lot of shadow accounts, users that have more than one wallet without them even knowing.
The AUB is just a matter of seeding a number of developer-controlled user accounts.

The same reason you give for disapproving KRE 4.0 can also be used to disapprove 3.0.
However, in the current KRE, the cheating developer gets a higher KRE at the expense of your payout.
There is a fixed amount available Kin per day and the more the cheater gets, the smaller your piece of the pie.

KRE 4.0 however pays you exactly what is due.
You no longer have to worry about the honesty of other developers. No more competition is needed.

There is another good reason.
KRE 3.0 pays out regardless of what effect the developer has on the Kin economy.
Even if it's just passing money on to others.
This means that KRE 3.0 only causes inflation in those cases.

Even if KRE 4.0 is gamed as much as 3.0, we're better off. With 4.0 there is at least an incentive for Economic Activity. KRE money is being used for what it is intended for....promoting the flow of Kin through the economy. That's something 3.0 definitely doesn't do.

What strikes me is the kind of developers that are apparently attracted to KRE 3.0. The biggest problem always seems to be that they cheat. In fact it is the only concern I hear so far on the proposal.

Unfortunately free money also attracts people who are actually not real entrepreneurs. It is not an easy job. You have to make an effort to offer good products that people are willing to pay for. You have to take risks, advertise and invest money yourself.

So the idea that a KRE fully provides your income is very attractive.
It feels like the security of a paid employment.
It's like the guaranteed purchase of your product, something that no entrepreneur has.

But even that is just appearance. Only the top 3 in the KRE may be able to live on that income. The rest absolutely not.
And the more apps are added, the lower the payouts will be.
That is the future for KRE 3.0.
Nobody will be able to live off it when we have 50+ apps.

But back to the gaming possibilities.
What they can try is to take money from their own cash register and spend it in their own app… over and over again.
They can buy their own products with their own money.

Is that what you mean, or do you see other dangers?

My 2nd question is:
Aside from the alleged gaming opportunity, what do you think of the proposal to reward developers for generating more revenue? That they are helped to generate an income themselves with a 30% bonus?

And if you don't like that, how do you see KRE 3.0 providing the income of 50 or more developers? Should we increase the KRE from 250MM to 500MM per day?
You prefere the current KRE.
This KRE, however, reduces this amount per year.

And above all....who is going to pay for all those incomes?

[ted-livingston]

One thought reading your comment amiraliaaa and your reply Freedom - what if the payout was based on "AUB growth” versus "AUB total"? Such that developers get rewarded for how much they increase their AUB, versus total AUB they have? This way big devs need to keep growing, and small devs can compete too.

Their growth would have to be compared to their high water mark. This could be daunting as all their revenue would go to zero as soon as their AUB stopped growing. In such a case we couldn’t just reset their high water mark, as that would be easy to game, but perhaps there could be some “cooling off” function where their high water mark would slowly get lowered if they weren’t hitting it anymore until they were hitting it once again.

What do you two think of something like that?

[Freedom-kin]

The problem with rewarding AUB in any form is that once again it keeps Kin IN the wallets. Instead, we need to encourage it to come out and flow through the economy. Measuring AUB growth is just measuring how much more Kin has NOT been spent. It does not measure the growth of the economy.
I think we need to get rid of that whole AUB way of thinking.
We should not continue to reward keeping Kin IN wallets.

It feels like building a race car where you build a powerful engine into it to move forward quickly...but then you hang a block of concrete behind it that acts like an anchor. The wheels turn but don't move forward, digging themselves more and more into the sand, until you're stuck. Kin doesn't move forward.
That is what rewarding the AUB does...it just causes more and more inflation, until Kin is worth nothing...and then we're stuck.

KRE is a powerful engine...but most of its power is used, and lost, dragging the AUB.
Let the AUB go and you shoot forward.

[amiraliaaa]

I think relying on AUB encourages users to hold their Kin and not to liquidate their assets which helps the price to increase. I understand that a healthy trading volume is also needed and thats where spends come into play. Thats why I think the KRE formula should include both AUB and spends as the main parameters with perhaps more focus on AUB to allow established apps to benefit from the KRE and big apps to join the ecosystem.
I also agree with you Ted that we need to somehow create a system that small devs can also compete. AUB growth can also be one of the parameters in the formula. Maybe the formula can consist of three factors: 1) AUB 2) Spends 3) Some way to measure growth like AUB growth

[Freedom-kin]

Ameralia, AUB encourages developers to ensure that users keep their Kin in their wallet. Their pay check depents on it. That Kin is not spent, so it impedes the flow of Kin through the economy, while that is what drives Economic Activity.

The claim that it prevents users from liquidating their Kin and that it helps increase the price of Kin is hopelessly outdated. Selling on exchanges is big and the price is extremely low. This despite more than a year rewarding AUB.

Measuring AUB growth is measuring how much more Kin is NOT spent.
The more that grows, the worse it is for the economy.