add fasol bot

[clizzard7]

add trades, schema and seed for Fasol Trading Bot (SOLANA)
Dune dashboard TBD
https://x.com/fasol_robot

[Hosuke]

LGTM.✅
Thank you @clizzard7

Sample fasol_solana_bot_trades

[Hosuke]

Maybe you can add your credit:

Suggested change

	contributors: whale_hunter
	contributors: whale_hunter, clizzard7

[jeff-dude]

i think we should consider this one similar to photon, even though it finished in CI (though it took almost the full 90m)

[whalehunting]

@jeff-dude we had a discussion on how to improve performance (next to the changes @Hosuke made here) and decided to split fee payments and trades into separate spellbooks. hope this improves it, lmk if you have other ideas on this!

[jeff-dude]

thanks for first step to break this up a bit. i think we need to take it a step further, seeing as it's still timing out in CI on a pretty good size cluster.

let's consider the dex_solana.trades pipeline. the architecture goes like this:

• project level model, with decoded sources + few joins to essentials such as transfers, token accounts, etc
  • for bot trades, this would be the bot level models (like fasol here)
• cross-project base_trades model which unions all projects and nothing else
  • for bot trades, this would union each bot model
• final dex_solana.trades, which joins in metadata related info, with prices being a big part of that (prices is a large table, making joins expensive to do often)

with that in mind, can we break out bot trades pipeline to match something similar? we can start with fasol only here, then continue to add the others into the new dex_solana.base_bot_trades introduced. you can try with first only removing prices from bot-level models, then add prices back in the final dex_solana.bot_trades model. if it's still not performant, we can consider removing the join to solana.transactions and standardize that at another level downstream too.

looking closer at transactions table, looks like that is only used to filter out tx's. is there a world where we can build a spell upstream of this, similar to fees, which loads all tx's by that fee receiver? and maybe we can even make it universal, where you add a project field or something to separate rows from one another, then use it for any bot trades model that filters the same way? then that intermediate table can be just distinct project/id/signer?