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.