View this article in it’s original form on!


During my ages-long hobby of creating bots to offer to the general public, I’ve ran into a question that most entrepreneurs will face at some point: What sort of revenue model will I employ? Let’s look at some common ones in my niche and compare.


Probably my favorite on paper is crowdsourcing the money to run a bot. It has some distinct advantages: if you have more and more capital on one account, exchanges like Binance have less and less fees.

For a lot of my bots, the edge over the market comes from incremental increases in the amount of profit each trading cycle brings in – and, for instance, the market maker bot’s incomes are almost entirely dependent on the fee rebates (where applicable) and the % between bid and ask. Having even less fees when trading with this much vitality is important – and can create significant boosts to yield.

The detriments are, of course, that you then become an extra single point of failure and people don’t tend to trust their funds to these sorts of operations. ‘Do Your Own Research’ is in full swing in the crypto community – also putting a heavy weight on your shoulders – and I commend it! It leaves crowdfunding as an option best kept among a small circle of friends, though.

Free and Open Source Software

Also helpful is free and open source software – as it helps drive your traffic and credibility. My Github boasts over 100 distinct FOSS repositories, driving quality and qualified traffic to my chat rooms and email.

The drawback, of course, is that there is no direct income from this method.

Referral Fees

Another one of my favorites are referral fees – when someone uses your referral link, for instance for Binance, and you receive a cut of their fees. Sometimes this can be for a year or for the lifetime of the member’s use of that exchange.

This gives a certain vested interest in the bot – if your customers succeed, you succeed. However – if they fail, you succeed then, too 😛 All in all, if they continue using the software over a period of time and have continued success, then it drives your revenues.

The drawback here is that referral fees are only at max 3/10 of 1/10 of a % of the trade’s value – d’oh!


A subscription model is sometimes where I land for projects I’m confident about. It allows there to be a trustless relationship and allows you the benefit of having the subscription funds for the first interval of time upfront – where in others, you might have to wait (or never see revenue, at that).

The drawbacks are that people are hesitant to spend money where there might be a conceivable scam going on to separate them from their money – or, in a  more general sense, have a problem trusting other people. That’s ok, really! Crypto was invented so we could have trustless, decentralized systems.

Profit Share

Maybe the ultimate solution from these models is the profit share. If someone realizes gains of 10% in a month, I take 3% of the total (30% of the gains) and everyone’s winning.

If they lose, some people are looking for a guarantee – that is, having me or the organization at large pay for the losses as a kind of insurance. This doesn’t really make a whole lot of business sense, as you need to limit your downside potential. A profit share without insurance really does increase the upwards potential over subscription fee, though!


I’ve found that people don’t really take FOSS or Referral Fee revenue models all that seriously. There’s an insane correlation between price and quality that all these years of growing up in capitalist corporotacracy have left us with.

A mix of Subscription and Referral Fees or Profit Share and Referral Fees is probably best, in most cases – or offering both. If someone has a large amount of capital they wouldn’t want to sacrifice 30% in a profit share, and if someone only had a fraction of a ETH they wouldn’t want to pay 0.75 ETH a month in a subscription.


Look for new and upcoming bots, like this Sentiment Analysis (Name TBD) bot… the last two graphs are after implementing a trailing take profit and guessing at values for trigger and stop! These would need to be optimized by the use based on their aversion to risk.