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 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

* 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.

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.

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 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 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.