Threefold Referral Program

Threefold Referral Program

Hi there!

I thought about a way to use the solution provider program and the Proof-of-Utilization distribution to build a referral program for Threefold. Here’s the basic of what I have in mind. Please share your thoughts on this. Perhaps we can improve the basic idea with your help!

Table of Contents

The Proof-of-Utilization Potential

The following is the P-o-U current setup:

  • 50% goes to solution providers and sales channels*

  • 35% goes to TFT burning

  • 10% goes to the Threefold Foundation

  • 5% goes to the Validator Staking Pool

We thus have 50% available for solution providers and sales channels.

If the 50% isn’t used for solution providers and sales channels, it goes to the Threefold DAO owned Community Grant Wallet.

The Basic Concepts of a Referral Program

I will use the information available here to be quick.

Thus everyone understands the terms used.

Referral: The act or process of transferring something to another, of sending by reference, or referring.

Referrer (Brand Advocate/ Ambassador): a person who makes a referral/refers another (their friends, family and acquaintances).

Referee (Friend): a person who is invited to a referral/ referred by another.

Referral Programs: programs that are designed to specifically motivate the existing customers to help a business find new customers.

Viral Loop: a mechanism that has users refer others to a product or service and then turns those referees into referrers through the same mechanism.

Rewards: what participants in a referral program earn on successful completion of a referral.

Happy moment: the time when a referrer is most likely to make a referral due to a recent happy experience while using your product or service.

The Proposition for the Referral Program

We share the 50% of PoU to referee and referrer. This will encourage people to use the TF Grid and to talk about the TF Grid to their friends, etc.

The General Process

  • The referee uses the referrer’s link

  • The referee deploys on the TF Grid

  • At the end of the deployment, the TF DAO wallet sends half of the 50% to the referee and the other half to the referrer

The Basic Flow of the Referral Program

  • Someone uses the TF Grid and deploys a workload

  • This is the “happy moment”, as the TF user can see how amazing the Grid is

  • Threefold sends a message to invite the user to become a referrer.

  • Referral Message: “Did you enjoy deploying on TF Grid? If you want to, you can participe in our Threefold Referral Program, simply share this link [TF referral link, combined with the referrer’s 3bot ID] to your friends.”

  • The Referrer sends their link to a friend.

  • The friend is now a referee. The referee deploys on the TF Grid.

  • Once the deployment is done, the TF Grid knows the total amount of TFT used for this deployment

  • The TF DAO owned community Grant Wallet thus received 50% of the workload cost

  • The TF DAO wallet sends half of the “rewards” to the referee, and the other half to the referrer

  • The viral loop: the referee can easily become the referrer: they enjoyed deploying on the Grid, and they benefited from the referral program as a referee. They might want to also become a referrer.

Additional Information

Obviously this is a general draft of the proposition.
We can have variations.

For example, the referrer can easily be a Threefold farmer. It doesn’t have to be a user deploying on the TF Grid.


What do you guys think?

Would this be feasible?

How could this be coded into TF Grid’s smart contracts?

TF Referral Program Details

In order to avoid self-referral fraud, we could implement the following in the TF Referral Program:

  • there is a limit on referral rewards
    • e.g. 20$ worth of TFT maximum
  • to become a referrer, you need to have a proven history of using the TF Grid
    • users can become a referrer after they spent X amount of $ (or TFT) on the TF Grid

Yep. That’s a solid plan.

What would happen if the referee reserved a workload with an associated solution provider is the only thing I see as a pause, gbut I’m a huge fan beyond that one technical aspect.

I like that it’s based on however much the refree actually uses that lends to preventing some abuse,

any thoughts on preventing a situation where someone is able to essentially get cash back rewards on their vm by using their own code with two payout wallets?

There’s significant discussion about how to identify twins and their workloads going on here though, so that may have an in development solution soon.

Thanks @FLnelson and @ParkerS for your feedback.

I made the post simple without going into the potential issues to get it rolling. Very happy that you bring those 2 points Drew, as they are indeed important to settle.

  • “What would happen if the referee reserved a workload with an associated solution provider”
    • When a referee reserves a workload associated with a solution provider, the referee and the referrer could share half-half whatever remains after the other “associated solution provider” fees.
    • There could also be “TF messages” telling the deployer how much “% rewards” from the program they would get for the specific workload they want to deploy
    • for some workloads, the “rewards” might be 100% taken by the other “associated solution provider” fees, in that case, the users could choose another deployment if they still want the “referral program rewards”
  • “someone is able to essentially get cash back rewards on their vm by using their own code with two payout wallets”
    • worst case scenario: we can’t prevent it, but still the user needs to use the Grid and pay 50% of the workload
    • best case scenario: we can track this behaviour and prevent the wrongdoing
    • note: we could check what other companies do with the referral programs to avoid such wrongdoing

Yeah, there is abuse potential, but so what? There’s not enough utilization to matter. If things pick up then we won’t even need the referral program and can just end the promotion.

1 Like

So exploring the potential Referral Program Abuses.

Here’s a site:

  • Self-referrals: Some customers would refer themselves to get both a discount for a new purchase and a reward for referring someone. They do this by using different email addresses or creating new accounts at your ecommerce store.
  • Sharing on coupon sites: Instead of sharing their referral link and code with their friends, some would post them on coupon sites, discount sites, or forums. This allows them to get more people to use their referral link or code so that they can earn more rewards. But they are not genuinely referring their friends.
  • Return abuse: Some people would get their friends to use their referral link and code. Once they get the reward for “referring”, their friends would return the product and get a refund.

The second and third points are not relevant for our situation:

Sharing coupon on sites: even if people do this, it will still attract users to use the TF Grid. So I don’t think it’s a problem.

Return abuse: we only send the rewards after the deployment. So people can’t “return abuse”.

Self-referrals: that is the potential issue to this TF referral program. We’d need to find ways to prevent this. Or go with the flow, as @FLnelson just proposed above! “Better half of one, than all of none.”

Your right probably not important at this point.

Hi guys,

Surprised there ain’t more replies here, as I think it’s a very good program for Threefold in general!

Anyway. All is good.

So Theo Chapman sent me this link for referral programs:

Perhaps it could be an avenue for this TF referral program, or at least it could inspire some ideas.

If the community thinks this is a nice idea (TF referral program in general), we’d need to see how to implement it.

Personally, I think it’d be nice to have this 100% managed on the TF Grid, with smart contracts and the solution provider process.

Let us know what you think.

Currently, the solution provider/sales channel let’s try some new vocab here… the proof of utilization beneficiary must be registered in TF Chain after a vote of the DAO. After that happens, they their id can be tagged onto any contract and a predefined split of PoU rewards (50% of deployment costs). My thoughts on the challenges with shifting the mechanism to a referral program are enumerated below.


The first potential problem I see with allowing anyone to become a PoU beneficiary is that it short circuits the process above. Anyone can start earning as a solution provider or sales channel without requiring DAO approval, by simply using the referral mechanism instead. This could be a non problem, but it is a substantial departure from the existing design.


Another potential issue is reliably tagging the referrer’s id onto the referee’s contracts. With a solution provider or sales channel, we expect this to be done by the deploying interface, and done in the same way for every user. For the case of referrals, the only reliable way to track them would be on TF Chain. This is probably an acceptable and low impact change to TF Chain (small amount of on chain data added).


In considering the idea of an onchain referral mechanism, it occurred to me that without a solution for self-referral, there’s nothing to stop all referred newcomers from just creating a new account with their own referral code as soon as they arrive. So I think figuring that out is a requirement.

Some ideas:

  • Only accounts of a certain age can refer (helps but effectively only defers the problem)
  • Referrers must be approved by a DAO vote (doesn’t really solve the self referral problem)
  • Accounts are somehow tied to identity (that’s a big project in itself)

Overall, I think it’s a great idea to explore how we might be able to make referrals work for the grid. A final thought is that this might be simpler to implement into a proposed commercial service provider, rather than as a base feature of the Grid.

We are down to 1% utilization. We have nothing to lose, everything to gain. So what if someone abuses it? Its just magic internet money. We can end the promotion or edit how it works depending on how it goes. The biggest hurdle is the dev time to make it happen.

The specific flow I’m concerned about is this:

  1. Alice refers Bob
  2. Bob joins and see’s that now he has a referral code
  3. Bob self refers a new account and creates all his deployments there
  4. Alice doesn’t benefit from referring Bob

Self referral for the individual’s benefit isn’t the issue—it’s the fact that it breaks the incentive for the referrer too.

I see. Well, maybe they won’t be a clever as you.

I guess I shouldn’ta spilled the beans :laughing:

Been thinking about this a bit more, and something that might help would be capping the referral reward—to something like $20 equivalent. This would discourage self referrals because it would require recreating any deployments each time the cap was hit. That along with a stipulation that an account must spend so much TFT before it can start making referrals could make a winning recipe. Getting a bit complicated but not too bad.

That’s makes a lot of sense, don’t want those referrals adding up too long, make it $20 per deployment.

Looks like we’re heading with a consensus:

TF Referral Program Details

  • capping the referral rewards (e.g. 20$)
  • users can become a referrer after they spent X amount of $ (or TFT) on the TF Grid

I thus updated the original post, with the feedback from @FLnelson, @ParkerS and @scott

1 Like

Is that a max $20 per account signed up, or $20 per person distributing the code?

Good question.

@scott do you have something in mind?

You proposed the 20$, perhaps you have a model in mind.

Per account signed up.

So Alice refers Bob and then Alice can earn up to $20 equivalent in TFT from Bob’s deployments. It’s at that point that Bob becomes eligible to refer others.

Alice can continue earning an uncapped amount by referring additional users.


Just to be sure, once Alice earned 20$ in TFT from Bob, then Bob can become a referrer?

And what is the prerequisite for Alice to be able to refer?

Being picky, to make sure we cover everything!