Threefold Solution Provider and Sales Channel

Threefold Solution Provider and Sales Channel

Are you thinking about launching a solution on the Threefold Grid?

You could get up to 50% of all utilization revenues thanks to the Threefold Proof-of-Utilization distribution.

The Threefold Grid is in an exciting phase, where developers from around the world can now contribute and deploy solutions on the TF Grid while getting sales channel revenues.

  • The first section presents some basic questions and answers to help you understand the process.
  • The second section presents ongoing propositions and discussions around the concept of solution provider and sales channel.

If you have more questions, ask them here and we will be able to update the documentation and make this as clear as possible for anyone that desires to build on the Threefold Grid to become a solution provider.


Table of Contents

Q&A for Solution Provider and Sales Channel


How does Proof-of-Utilization work? How is the Threefold Token (TFT) distributed when there is utilization on the Threefold Grid?

Here are the general steps of the Proof-of-Utilization process:

  1. A user reserves Internet capacity on a given set of 3Nodes.

  2. Zero-OS records the reserved and used CU, SU, NU and IPAddresses in correlation with TFChain records.

  3. The TFChain DAO will charge the costs to the user in line with discount mechanism.

  4. TFT from the user account are burned/distributed in line to table below.

When people spend Threefold Tokens on the Threefold Grid for any kind of deployment, the TFT is distributed as per the Proof-of-Utilization distribution flow.

The Proof-of-Utilization distribution flow is the following:

  • 50% goes to the solution provider and/or the sales channel

  • 35% goes to TFT burning

  • 10% goes to the Threefold Foundation

  • 5% goes to the Validator Staking Pool

To see the Proof-of-Utilization distribution flow chart, check this link.

*Note: For billing purposes, ThreeFold DAO will check if the workload comes from a known sales channel and/or solution provider. If yes, then the billing smart contract code will know how to distribute the TFTs. If the sales channel and/or solution provider is not known, then the 50% will go to a DAO owned Community Grant Wallet.


What does it mean to be a solution provider on the Threefold Grid?

A solution provider offers a solution on the Threefold Grid and receives 50% of the TFT utilization revenues from the workload related to the solution.

A “solution” is something running on the grid, created by a community member. This can be brought forward to the council, who can vote on it to recognize it as a solution. On contract creation, a recognized solution can be referenced, in which case part of the payment goes toward the address coupled to the solution.

To become a solution provider, read the next question.


How can I become a solution provider on top of the Threefold Grid?

Threefold uses the Proof-of-Utilization distribution where 50% of the TFT utilization revenues goes to the solution provider offering a solution. If there is no solution provider associated with the deployment, the 50% revenues goes to a DAO owned Community Grant Wallet.

There are a few steps to follow to become a solution provider:

  1. Follow the steps detailed in this documentation

  2. Then write a Threefold Forum post explaining what the solution provider does

  3. Once the two first steps are done, a DAO proposal will be launched to decide if the solution is approved


What is the relation between a solution provider and a sales channel?

Those two concepts are closely linked.

On a technical level, the solution provider and the sales channel constitute a simple mechanism whereby up to 50% of the TFT spent on a deployment can be redirected to another wallet. The object in TF Chain that makes this possible, by linking the deployment contract and the wallet to be paid, is called a “solution provider”. This on-chain concept is thus called a solution provider, but it enables both solution providers and sales channels.


How can I receive a solution provider ID?

To receive a solution provider ID, you need to get approved as a solution provider.


Should solutions be open-source? Can I propose a closed-source solution?

It’s not required that a solution be open source, although it would be a good thing consider Threefold’s ethos and philosophy.

It is necessary that the 3Node deploying the solution is able to download the flist containing the solution from some location available over the public internet. Typically this done on the TF Hub, but it doesn’t have to be. It could also be possible to obscure the link to the Flist somehow in the deployment process. Regardless, the flist can contain binaries that are closed source and not licensed for free use.

This is an ongoing discussion and it should be taken on a case-by-case basis as solution providers step forward.


Propositions by the TF Community for Solution Provider and Sales Channel:


As we gather information on this project, and as TF community members discuss this topic, we will update this section with great ideas and propositions.

This is not a typical Q&A section. It is a way to document propositions by TF community members.


Present Solutions by Solution Providers on the TF Playground

One of the easiest ways to boost solution providers’ development would be to allow them to publish on the playground, where they will have broad audience available.


The Council/DAO should make sure a new solution isn’t just a duplicate of an existing one

It would be a great role for the council to verify that a solution provider application is not just a mere fork of an existing one. Otherwise, bad actors could simply steal previous solution providers’ idea. This is most certainly important to consider since the project is open-source in nature.


Taking the role of a solution provider, a sales channel or both at the same time

The concept of solution provider on the TF Grid encompasses both solution provider and sales channel (the TF contract on chain is called “solution provider”. But in reality, someone can be both or just one of the two, as shown below:

  • Solution provider: provide a new solution
  • Sales channel: market an existing solution
  • Solution provider + sales channel: provide a new solution + market the new solution

Finding a way to take into account those 3 configurations could help the project as it would enable collaborations and further possibilities.

This is not straight forward as it needs to be taken into account during the solution provider contract process. Technicalities should be considered.

1 Like

I feel like this has been answered before, but up to this day I’m still not sure if really understand the difference between Solution Provider and Sales Channel.

Solution providers are explained in this thread. Cool. So what are sales channels used for and how do they relate to solution providers?

I originally thought Sales Channels can simply act as marketing channels for capacity on the grid, generating a stream of new and ongoing customers, without having to implement custom
Solutions themselves. Like a motivation for farmers to go out there and actively sell their own capacity on the grid. Is that not something that we would want to enable?

+1 on this question

Solution provider is well defined now, but I don’t get the detail of sales channel, please elaborate

@jakubprogramming @archit3kt

Thanks for the feedback. That is exactly what we need in order to build clear documentation.

I rewrote most of the Q&A above, to include the distinction between solution provider and sales channel.

Is it clearer now? Let me know if you have the time to read it.

Thanks!

Hi @RobertL

I would say that all is not lost.

There are ways to go with your project.

In the documentation, you can read that there are up to 5 payout addresses associated with a given solution:

“Up to 5 payout addresses, each with a payout percentage. This is the percentage of the payout received by the associated address. The amount is deducted from the payout to the treasury and specified as percentage of the total contract cost.”


In you current situation, you could join force with other members of the Threefold community, and work on a solution.

For example, you could bring a great idea forward, find people that have time and skills to build the solution, and you could all build this solution as a team effort.

Then, you could make sure that everyone is paid their fair share, thanks to the payout addresses.


Still from the documentation:

“Example: 10% payout percentage to addr 1, 5% payout to addr 2. This means 15% goes to the 2 listed addresses combined and 35% goes to the treasury (instead of usual 50). Rest remains as is. If the cost would be 10TFT, 1TFT goes to the address1, 0.5TFT goes to address 2, 3.5TFT goes to the treasury, instead of the default 5TFT to the treasury”

So in your case, you could join with 1 other member of the TF community and get each 25% of the TFT utilization revenues linked to the solution.

What do you think?

1 Like

@jakubprogramming

What you wrote here does apply to a sales channel:

“Sales Channels can simply act as marketing channels for capacity on the grid, generating a stream of new and ongoing customers, without having to implement custom
Solutions themselves.”

It goes to show that we still need to refine how we explain those concepts.

See this post as a work in progress until we find the best way to explain it all.

So we need to have a clearer documentation on the sales channel process.

The solution provider is clear, but there is too much ambiguity between sales channel and solution provider.

I propose those 3 main templates.


  • Someone wants to market existing solutions and take a cut of the revenues

    • this is a sales channel
  • Someone wants to develop new solutions without promoting them

    • this is a solution provider
  • Someone wants to develop new solutions and market/promote those solutions

    • this is a solution provider also acting as a sales channel

I’m curious to see what the community members think about this.

Note: in general, Threefold uses the terms sales channel and solution provider interchangeably, but I think we’d need to clarify those concepts.

2 Likes

Hi everyone,

Let me see if I can help clear things up a bit. On a technical level, what we really have is a pretty simple mechanism whereby up to 50% of the TFT spent on a deployment can be redirected to another wallet. The object in TF Chain that makes this possible, by linking the deployment contract and the wallet to be paid, is called a “solution provider”. That’s confusing, because this is the single on chain concept that enables both solution providers and sales channels as mentioned in the wiki.

There’s also a pretty simple intention behind introducing this concept in Grid 3, which is to provide a way to reward those who drive utilization of the Grid. Someone who is doing that and getting paid according to this mechanism falls under the umbrella of “solution providers and sales channels”. If part of the process was bringing a new solution to the Grid, probably we’d call that a “solution provider”, but being successful at that will probably involve being a “sales channel” as well. If someone just wants to market generic VMs or existing solutions, probably they’d be called a “sales channel”.

As far as the registration goes, this is a first version of the process, which should be integrated into the dashboard at some point. That said, while it looks complicated, it’s really just filling a few pieces of information into a form.

I guess you’re asking if there should be a simpler way for people to get involved in marketing capacity and thus be rewarded as a sales channel. That seems to me like a worthwhile idea we could explore (maybe some kind of affiliate link model), but at this stage of development, some technical involvement is probably required.

Exactly.

So there should be some more nuances to separate the 3 possibilities:

  1. Solution provider: provide a new solution
  2. Sales channel: market an existing solution
  3. Solution provider + sales channel: provide a new solution + market the new solution

Basically, we’d need some clear steps for people that want to do solely sales channel.
Then a solution provider could decide to also be a sales channel.

This is very attractive to me, I can easily see starting out as a sales channel for a library of solutions and then quickly coming up with new solutions as different services gain traction turning into a solution provider by building new unique solutions that do not exist but have demand.

2 Likes

After some talk with @scott, here’s something to add.

Continuing on the concept of being 3 types:

  1. Solution provider: provide a new solution
  2. Sales channel: market an existing solution
  3. Solution provider + sales channel: provide a new solution + market the new solution

Here’s how we could do it, with an example to show the general idea:

Someone provides a new solution. He is a solution provider.
He doesn’t market the solution.

He decides he wants the total 50% of the revenues from the PoU distribution.
BUT he also chooses to give, say half of it, 25%, to any sales channel marketing his solution.


I don’t know how it is coded exactly (the solution provider on TFChain), BUT, it could simply be an " if " statement coupled with the fact that there are up to 5 addresses in the “solution provider” TFChain contract.

Continuing the example:

Say you split the 50% into sales channel and solution provider equally:
If there is no sales channel, the solution provider takes all the revenues.
Otherwise, the sales channel gets 25% and the solution provider gets 25%.

This would then incite people to act as a sales channel even if they did not provide a new solution on the TF Grid. This is much in line with @fromenator’s reply above.

Just for fun, here’s a pseudo-code to show the idea:

PSEUDO-CODE:

revenue_sales_channel = 0.25
revenue_solution_provider = 0.25

if sales_channel_present = false :
wallet_address_sales_channel = wallet_address_solution_provider
endif

wallet_address_solution_provider += deployment_cost * revenue_solution_provider
wallet_address_sales_channel += deployment_cost * revenue_sales_channel


What do you guys think?

If I’m creating a solution, does it have to be open source ? Because if I publish it on github and someone fork the repo and create another solution to have the funds and market it better, it would be problematic… Maybe the council role is to prevent this ?

Also can the solution be published on the playground to get wider audience ?

Right now I don’t see how a sales channel could work, since the two ways to deploy on the grid is playground and terraform… An example would be welcome

Thanks for your explanation!

The only thing I can think of is that the sales channel is the new solution TF is working on where for instance hosting companies could offer cloud hosting accepting fiat currency. Just my guess

It’s not required that a solution be open source, although I think it would be a big plus. It is necessary that the 3Node is able to download the flist containing the solution from some location available over the public internet. Typically this is our hub, but it doesn’t have to be. I suppose it could also be possible to obscure the link to the flist somehow in the deployment process. Regardless, the flist can contain binaries that are closed source and not licensed for free use.

Personally I think one of the most exciting features of the Grid is the level of security and transparency that comes with running open source code on an autonomous platform with no admins who can interfere with execution. Your concern is certainly valid and I think there are ways to address it in an open source environment. One way would be to simply not approve the second solution provider who copied the work. Another way would be to have their solution pay some part of the fees to the original creator.

Speaking of open source, the response to your second concern is that anyone can fork the code for the playground or the mastodon deployer. This could be useful for sales channels and solution providers to get a jump start on building an interface for their users. Of course, they could also start with the underlying libraries that facilitate deployments on the Grid and build something from scratch.

As for publishing solutions on the playground, we don’t have any process for that yet but I think it’s something we can definitely consider on a case by case basis. No one has come forward with a solution to be included yet, but it would be great to see.

1 Like

I’m a fan of open source too, and it would be a great role for the council to verify that a solution provider application is not just a mere fork of an existing one ! I hope you will go on this road.

IMHO at the moment the easiest way to boost solution providers development would be to allow them to publish on the playground, where they will have broad audience available. I also hope you will go on this road :smiley:

If that’s the case, I’d like to develop a resilient HA k3s solution ready to go, with rancher and longhorn enabled out of the box, for easy cloud management and easy deployment from the playground. What do you think ?

I think it sounds like an amazing project: HA k3s solution ready to go.

I also think the two points you brought are very sound.

The process will be refined as people go through it. It’d be amazing if you were one of the first to offer a solution.

The council should indeed make sure new solutions are not a duplicate of another previous solution.
And indeed presenting the solution on the Playground, if it fits all correct specs to be there, would be a good thing, both for the grid and the solution provider. This point should be stated clearly in the solution provider demand for the DAO/Council. Simply stating: I want this solution to be offered on the Playground should suffice.

@archit3kt @scott @RobertL @fromenator @jakubprogramming

As I wrote in the original post, this post is updated as new information comes in.

I added a new section to take into account the great propositions and ideas you guys have brought forward.

This is still an ongoing project and we appreciate everyone’s feedback.

Thanks!

1 Like

Sorry, don’t understand. Where can we find this section?

It may be an idea like @archit3kt did for me to mention my idea too, before it gets highjacked. It might take some more time for me to install and test everything before asking for additional help, but it’ll be good to share it somewhere.

I added the section:

Propositions by the TF Community for Solution Provider and Sales Channel:

Also, added a Q&A about closed-source solutions.


I think it’s a good idea to state/share your idea on the forum indeed.
So we know you’re working on this. Then you could have priority in a sense.

Also, perhaps you’ll find members that would like to help.