Fairpool

We talked about the CryptoGPT idea.

We talked about rewriting our decision-making system in Rust and obtaining probabilistic proofs of one strategy being better than another.

We talked about the technical limitations of the Optimism stack & the potential of Cosmos SDK.

We talked about a new type of content that we can create using ChatGPT.

We've described the Freechain idea.

We talked about our experience of using Haskell for our decision-making system.

We talked about solving user intents & the Suave blockchain.

We talked about using SMT solvers to build better models of reality.

We talked about using a formal language to describe how things work.

We talked about proving theorems for finite data using massively parallel evaluation.

We talked about a common language for communicating within a team.

We talked about "controlled point-free programming" - a better way to write functions. It's a restricted version of the general point-free programming, which forces the developer to write the functions more clearly.

We talked about two approaches to software development: top-down & bottom-up (specification-first and implementation-first).

We talked about a novel approach to task management: presenting tasks as files with executable code. This allows skipping the frontend, thus saving time & money on development.

We talked about zero-dependency functions & executing WASM code on the server.

We talked about writing specifications in a regular imperative language.

We talked about the connection between the code actions & code-generating AI.

We talked about a new revenue stream for our company - selling code actions.

We talked about the hierarchical updates of the state & the agents - this is optimization of our decision-making system.

We talked about specifics of applying the universal estimator to business decisions (in particular: hiring).

We talked about mitigating OTC trades on Fairpool contracts.

Since every Fairpool contract has a `transfer` function, it's possible to buy & sell the tokens through other contracts. However, no taxes are taken on such transactions, which means that current token holders and current promoters would not benefit from it.

Of course, we can't just block the `transfer` function because there are legitimate use cases for it.

However, we've designed a mechanism that could mitigate the impact of such "external trading" - in essence, we would increment the special "transfer allowance" variable on a `buy` transaction and decrement it on either `sell` or `transfer` transaction. This way, the recipient of the transfer would not receive any transfer allowance, and thus won't be able to transfer the tokens further. It is also possible to implement it in a way that would allow a chain of transfers but of limited length (so that it would be possible to make N transfers, but not N+1).

We hope that such solution would keep the majority of the trading volume going through the contract.

We talked about security properties of different crypto storage systems.

We observe that it's impossible to define the probability of a specific wallet being hacked. We know that it's possible, but we don't know the probability. Therefore, we can't calculate the security of a specific signature scheme precisely.

However, we know that increasing the heterogeneity of the schema leads to a higher security. For example, using multiple different wallets is more secure than using a single wallet.

Essentially, we're responding to randomness by layering - we're requiring a longer sequence of events to happen before the final bad event.

You can imagine that we're "barricading" our crypto behind multiple layers of protection to make it more resistant against the attacks.

We talked about our approach to growing the company treasury.

We talked about building better UIs for crypto projects.

Our project, Fairpool, is pretty easy to use - it's an exchange, it allows to buy & sell tokens, but even with such a simple functionality some people get lost.

Additionally, users have a lot of questions about the projects even before they try to use the functionality. How does it work in general, what are the benefits, what are the fees, etc, etc.

We feel that such questions could be answered by a neural network, and that it could also detect the user intents & generate the frontend on-the-fly.

We'll try this idea for our project, and if it works, we'll offer it to other crypto startups.

We talked about "taking the high road" - developing a deeper understanding of the system.

Building a successful product requires making a lot of difficult decisions. It requires a deeper understanding of the customer needs, of the current technologies, of the regulations, etc. Even then, the chance of success is pretty slim.

So we believe it's prudent to invest our time in a decision-making system instead of plunging headlong into the market.

We talked about "tool marketing": building small focused tools & giving them away for free (as marketing).

With LLMs, we can build a lot of small tools cheaply. If the tool is valuable, people will share it with friends naturally. If the tool can show links to other products, we can give them away for free & use them for marketing.

Examples of the tools include: receiving notifications when something happens, performing batch actions (e.g. revoking allowances), converting the data into another format, etc.

New products always lack the tooling around it. If we build the tools & simply share them on product-specific groups, the users will pick them up naturally.

We'll try this idea to build up attention for our main product (Fairpool).

Is it rational to chase yield? We examined the process of making an investment decision with imperfect information.

The takeaway is that it's rational to use battle-tested & well-known methods to generate yield (like staking ETH or lending other assets via Aave), but it's irrational to maximize the yield via less-known projects.

We talked about the verification of the environment.

We arrived at the two conclusions:

1. The environment is a program. It will be run many, many times while training the agent. Thus, it can be battle-tested with runtime assertions. Such assertions would crash the environment, and we would inspect the stack trace & the logs to understand the root cause of the bug.

2. The environment is our model of the real world. Thus, it encodes our assumptions. If only a small number of people are responsible for verifying the environment, it's going to conform to the assumptions of those people - but it might not be enough. Indeed, the more people we can involve in the development of the environment, the better. So it makes sense to open-source the basic building blocks of the environment (but not the complete environment), so that other people could use those building blocks in their apps, and report bugs / open pull requests with fixes.

We clarified our strategy: why we're working on a decision-making system instead of "just building products".

We're sick of making ad-hoc decisions based on "intuition". It clearly doesn't work in counter-intuitive domains. The high percentage of failures among the startups is a hint that it's a counter-intuitive domain. The general advice on startups confirms this point. So we're taking a slower-but-steadier approach of building a model of the environment for our business & defining a policy that "wins" in this environment - essentially, writing the decision-making system for our company.

* Binance & Coinbase have been sued by the SEC.

* Both exchanges took a defensive stance.

* The SEC alleges that Binance.US has routed the customer money to investment funds - we're not sure if it's true, but if it is, then Binance.US may not have enough money to handle all withdrawals.

* Binance International may provide a "loan" to Binance.US to cover the withdrawals. However, this loan may require using the customer funds from Binance International itself. This is pure speculation, and personally I believe it's unlikely, but it's still better not to hold any funds on Binance during the investigation.

* This is a battle between new & old. I hope Binance & Coinbase have enough supporters to overthrow the case. If that happens, it will open a new chapter in the crypto history. If investing-by-buying-tokens is fully legalized, we'll see many more companies adopting it.

We talked about attack vectors in crypto.

Broadly speaking, the attack vectors can be divided into "physical" and "logical".

Physical attack vectors:

* Theft

* Extortion

* Kidnapping

* Duplication (physical copy)

Logical attack vectors:

* Without secret extraction

* With secret extraction

Logical attack vectors without secret extraction:

* Phishing

* Spoofing

* Social engineering ("Claim your airdrop", etc)

Logical attack vectors with secret extraction:

* Side channel attacks

* Code dependency attacks

* Weak password decryption

* Signature algorithm hacks

* Malware

* Ransomware

Lastly, we have events that are not attacks but still lead to loss-of-funds:

* Forgetting the password

* Loss of multiple backups

We'll be researching the best strategy for dealing with those threats.

We talked about the concept of the critical mass in marketing.

The customer needs to hear a marketing message from multiple sources before they can make the decision according to this message.

We think that in crypto, the required number of sources is actually even higher than a traditional marketing because in crypto it's vital to buy before others buy, which means the (future) opinions of others become more important.

Because of that, we think it's better to promote a crypto product through a larger pool of smaller influencers with overlapping audiences. The last point is crucial, because it allows to transfer the same message to the same customer multiple times.

We talked about building a correct environment for the neural network (AI CEO).

It's possible to train a neural network that runs the company. However, such networks are different from ChatGPT and other LLMs because they are trained to achieve a specific numeric goal (e.g. maximize revenue) in an adversarial environment.

Building such an environment is a challenge, especially for a crypto project: the demand for our product depends heavily on the market cycle, and it's hard to predict.

So initially, we're going to build a minor environment to test the hypothesis that a neural network can run a business.

For more details, please listen to the AMA.

We talked about exploiting new marketing channels.

Facebook, Twitter, TikTok are old marketing channels. The cost of promoting a new token is high, and it's hard to predict the ROI.

However, there are new marketing channels with low cost of promotion. Some of these marketing channels are not even called "marketing channels", and these are the most valuable ones.

For example, in the early days of Uniswap it was possible to get featured on the first page just by deploying a pool and getting some volume there. Later the competition increased, so the volume threshold got higher, but in the beginning it was possible.

Now, marketing specialists wouldn't call the first page of Uniswap a marketing channel. But it was, because people paid attention to it!

Another marketing channel that's recently become available is Blockscan Chat on Etherscan. It allows sending messages to specific addresses. Of course, there is spam protection, so it can't be used for mass sending. However, it's still useful for sending targeted messages that won't get classified as spam.

We talked about Ethereum staking platforms.

Some time ago we've converted our USDC to ETH. This ETH can be staked. It makes sense for us to do it, since ETH staking withdrawals have been enabled with the recent fork, so our capital won't be tied for a long time.

We've currently shortlisted Blox as a non-custodial SaaS provider.

Looking forward to expanding our runway through native staking!

We talked about the recent hacks that occurred over the crypto space (looks like the hacker got access to wallet seeds) & about staking our treasury to extend the runway.

We talked about the scaling of startups.

Recently, Paul Graham tweeted that scaling the startup prematurely is the single most dangerous mistake founders can make. He also mentioned two causes: wishful thinking on the part of founders & pushing to scale on the part of investors.

However, there's no definition of what it means to "scale prematurely". We propose an approximate definition: "to increase the bet size without a proof of positive expectation".

This definition implies that the founders need to produce a "proof" that their startup has a positive expectation of profit. How can they do it?

Broadly speaking, there are two ways:

* Extrapolate from data

* Extract axioms from data, then produce a proof using the axioms

There is a fundamental difference between two methods:

* The first method takes an "average" of all available data.

* The second method filters the dataset to include only the data that has "never failed" (is not random)

Additionally, the second method uses the external data - all other axioms from all branches of science.

We think the second method is superior, but it takes more time. Additionally, it may be necessary to introduce additional axioms to complete the proof. Such additional axioms may have low "support" (i.e. occur in data only a few times), so they can be invalidated in the near future.

However, with the recent advances in machine learning, it's conceivable to have an AI agent that could prove the theorems quickly. This would open the way to using the second approach.

Looking forward!

We talked about using AI to run the business.

ChatGPT is all the rage now, but there is a more important innovation that's flying under the radar. It's called DreamerV3 - a neural network architecture that's capable of finding an optimal strategy in an open world without pre-training.

DreamerV3 has achieved favorable performance in many games. However, its most important achievement is finding diamonds in Minecraft - a game which is very much like our real world.

In order to use DreamerV3, it's necessary to build a world in which it could operate. Thus, it's not immediately accessible to most businesses. However, we think that businesses using DreamerV3 are the businesses of the future.

We'll continue the development of Fairpool, but at some point we'll definitely try this neural network.

We've talked about the functionality for changing the referral addresses.

We want to decide whether we need to allow the user to change their referrals. When the users buys the tokens, his address is associated with a referral address of an influencer.

Should the user be able to change the referral address? ("switch" to another influencer)

On one hand, yes - because it gives the user more choice and stimulates the influencer to work harder to maintain the user.

On the other hand, no - because the influencer might not want to promote Fairpool if he/she would know that the user could just change the address.

Currently, we're leaning towards "no", since it would simplify the contract & it would be better for the influencers. Please let us know your feedback on this question.

We talked about the general applicability of the formal languages in business.

Initially, we turned to formal languages because we wanted to verify the Fairpool smart contract. But actually the formal languages have much broader applications. For example, they allow making decisions with any level of precision. Additionally, they allow to execute those decisions as programs - automating what could be automated, delegating to humans what couldn't be automated.

This is a very powerful paradigm, especially in the era of generative neural networks.

The generative networks (Midjourney, ChatGPT) require prompts as inputs. The prompts are supposed to describe the desired result. But it's not possible to describe the result precisely in an informal language. That's why the generative networks usually don't perform well at complex task that require generation of a lot of code.

Instead, we can use a formal language to fully specify the behavior of the program, and then ask the neural network to generate a program which passes those tests. If it generates a program that doesn't match the tests, it can try again, taking the compiler errors as an additional input.

We think this approach is extremely powerful - it's the way that the programs will be written in the future.

We've talked about formal verification of the smart contracts.

We want to ensure that our smart contract doesn't lose money. While it's impossible to get a 100% proof of the absence of bugs, it's possible to test the critical parts of the contract using formal methods. Using formal methods = proving theorems about the contract code.

We're currently experimenting with Lean 4 for the purposes of the contract code verification. Our current goal is to build a model of the contract in Lean, prove theorems about the contract functions, then write a script that executes random transactions on the contract & checks that the output of those transactions is equal to the output of the Lean model (in other words: that Solidity code is equivalent to Lean code).

Again, this won't give us 100% guarantee, but it would give us a much higher assurance than regular testing.

We talked about the permissions system of the Fairpool shares.

The Fairpool contract distributes the trading fees to multiple parties:

* The seller

* The current holders

* The referrals of the seller

* The contract owners (marketers, developers)

The Fairpool contract should work for multiple use cases, ranging from personal tokens to DAOs. Therefore, it's better to implement a dynamic list of shares.

However, the shares must be protected with a permissions system to ensure that every change to shares is fair.

The basic definitions of the permissions system are:

* Share values - numerator, children

* Share bounds - numeratorMin, numeratorMax, childrenNumeratorsSumMax, childrenNumeratorsSumMin

* Share fields - any of share values, any of share bounds

The basic principles of the permissions system are:

* Each share field has an array of owners

* Changing a share field requires signatures of all owners of that particular field.

The signatures are checked on-chain using native EVM functions.

This allows building shares where changing the numerator within bounds requires only a signature of a single share beneficiary, but changing numeratorMax requires signatures of share beneficiary & parent share owners.

We talked about ways to close the loophole in the earnings distribution algorithm.

Ideally, the earnings would be distributed to every holder on every transaction. However, that would require a lot of gas. The required amount may exceed the block gas limit. This is unacceptable, so we have implemented a workaround.

We randomly select 256 holders for each distribution. However, it's possible for the exploiter to buy very small amounts from multiple addresses, thus increasing his/her chance to appear in the distribution. There are two ways to fix this.

First, introduce a min amount for participation. This would increase the cost of the exploit to a point where the exploiter becomes a legit holder (puts a lot of money into the contract). 

Second, randomize the "step" variable, so that the selection is not contiguous. This way, exploiter couldn't benefit from securing a contiguous array of addresses.

We're currently working on implementing those fixes.

P.S. Happy Women's Day!

We talked about the enforcement of the trading fees on the Fairpool contract.

When the user sells the tokens, the Fairpool contract charges trading fees. When the user transfers the tokens to a different address, the contract doesn't charge the trading fees.

However, the transfer function could be abused to circumvent the fees. The user could make a deal through the OTC marketplace or just another exchange. In this case, the user won't need to call the sell function.

It's good for the particular user who wants to sell the tokens. It's bad for the remaining holders, because they won't receive the trading fees.

We propose the following solution: enable the stakeholders of the contract to turn on the fee-on-transfer mechanism, and make this fee dynamic (automatically increased on each transfer). The fee would increase up to the trading fee that would be charged on sell transaction.

Importantly, the fee would be turned off in the beginning, so that people would be able to freely transfer the token after the initial contract deployment.

To turn on the fee, a consensus of the contract stakeholders would be needed. Basically, a quorum of users who receive the trading fees would need to vote positively to turn on the fee.

What do you think about this idea?

We've finished the transition to the new pricing formula in the Fairpool smart contract.

We've also contacted multiple auditors & reached a preliminary agreement with Zokyo (our private investors).

We're currently updating the Fairpool contract with minor yet important functionality: the agent fee distribution & the referral fee distribution.

The agent fee is distributed on every sell transaction to the agent - the person who has referred the token creator to us.

The referral fee is distributed on every sell transaction to the referrer - the person who posts a link to the token page on his/her social media. The referrer address will be associated with the user address on the first buy transaction, and this association will be permanent.

We're changing the Fairpool pricing curve.

During the feedback sessions with potential users, we've had a hard time explaining how the pricing curve works. The most difficult part was explaining how the pricing curve parameters influence the shape of the curve. So we've decided to change the pricing curve formula to make it easier to understand.

Coincidentally, the parameters will also become simpler: instead of "multiplier" and "exponent", we'll have "total supply" and "initial price". The new parameter names are self-explanatory, and in the preliminary feedback that we've received before implementing the change, the users have also said that the new parameters are easier to understand.

So we're currently working on changing the price curve & getting more feedback from users. Stay tuned!

We've talked about current progress.

First of all, we've deployed a couple of tokens on Goerli testnet. We're currently making improvements & fixing minor bugs in the UI, to ensure that the users would have a good first experience.

We're planning to go to Dubai for networking - it's likely we'll get some good contacts there.

We're also expanding our team - hiring a blockchain developer and a frontend specialist. If you know someone who would be interested, please let us know.

And the last - but not the least - we'd like to mention the Fairpool Agent program. If you refer an influencer to us, and he/she creates a token, you'll receive up to $50000 in the native blockchain currency (e.g. ETH). The referral fees will be distributed by the contract itself. You'll receive 1.25% from every sell transaction. At $100000 daily volume, you'll receive $1250 daily, so you'll get the full $50000 within 40 days. If you know any influencers - reach out!

We have migrated the Fairpool contract to a better pricing formula.

While migrating, we have discovered an interesting fact: the bonding curve parameters don't matter for the purposes of taking profit.

For example:

• Alice buys for 1 ETH
• Bob buys for 10 ETH
• Alice sells for X ETH (X > 1)

Alice profit is the same no matter what the bonding curve parameters are. This seems weird, because the price changes differently depending on parameters. However, if the price increases faster, that means the initial purchase for 1 ETH gives Alice less tokens. So when she takes profit, she sells less tokens, but gets the same profit (because, again, the price increases faster).

In other words, the increase of price cancels out. We've run the tests, and they confirmed this finding.

We'll still allow the influencers to choose the bonding curve parameters, but we'll narrow down the range of choice (allow only the exponential curves, which look attractive to speculators).

We talked about whitelabeling of smart contracts - a special licensing agreement that allows forking the smart contracts, but only if the developer address is kept in the contract, so that it continues to receive the fees as recurring revenue.

We think it's the optimal solution for the blockchain development dilemma - should we release the code under permissive or restrictive license?

We must release the code anyway because we have to verify the contract on the block explorer. So the only question is - what license to use?

Whitelabeling answers this question in two ways - first, use a restrictive license in the code submitted to the block explorer, second, add a paragraph saying that you're open to whitelabeling (legal forking).

The other developers would then sign the whitelabeling agreement & develop their own products on top of the smart contracts (new UIs with better features, or even larger smart contract systems which extend the existing code).

Since the fees are split in a fair way, everyone is happy - both the original developer and the fork developer receive the recurring revenue.

We'll keep ourselves focused on the agent program, but we'll also keep our eyes open for whitelabeling opportunities.