Ape/rture

@aperture

145 Following

69 Followers

Brock pfp

@runninyeti.eth

I'll be speaking at the /avalanche Summit🔺 on May 21st on how to Love Your Data Again Reach out if you'll be in town!

0 reply

2 recasts

5 reactions

Ape/rture pfp

0 reply

0 recast

2 reactions

Ape/rture pfp

Not sure what that means for your indexers, but this is how I view it how we plan to solve it with The Indexing Company and the indexers we provide. https://x.com/ape_rture/status/1912818188779241753

0 reply

0 recast

0 reaction

Ape/rture pfp

Hence why you don't have to do the indexing in-house. You can let The Indexing Company handle that, so you get the data inhouse in your own database. Then you can focus on building the logic.

0 reply

0 recast

1 reaction

Ape/rture pfp

I think the problem with most parties is that they can't handle the throughput indeed. Pricing realtime is mostly just a query into the pool requested. For USD you can then match the last trades from other pools for that base pair. You can do that on query when a user asks for it. So lets say you have AAVE/ETH, you then match with ETH/USDC and/or ETH/USDT or ETH/USD from CEX

0 reply

0 recast

0 reaction

Ape/rture pfp

Maybe there is something we can do from the Indexing Company side. We can filter on any data that is on-chain and support Zora. Feel free to DM me! https://docs.indexing.co/networks/zora

1 reply

0 recast

1 reaction

Ape/rture pfp

What data are you trying to fetch? We are supporting Zora at The Indexing Company, potentially we can help stream that data to your database so you can query as much as you want. https://docs.indexing.co/networks/zora

0 reply

0 recast

0 reaction

Brock pfp

@runninyeti.eth

Building /indexing, infra for the distributed world Last week was mostly R&D: - Began planning a Neighborhood for token data -> more on that in coming weeks - Deeper SQLite work for universal queues - Cleanup work for asset tracking across Aptos, Sui, and Solana Happy Easter 🐰

0 reply

2 recasts

10 reactions

Ape/rture pfp

If you mean the decoding of the function call, yes we can do that either by event signature or ABI. If it is a read only function call we could also incorporate this in the pipelines if needed. You can assume this works for any chain you need it for. Do you have a specific example since that makes answering this question easier.

1 reply

0 recast

0 reaction

Ape/rture pfp

It's never too late to improve your sleep 😉

0 reply

0 recast

0 reaction

Ape/rture pfp

if you need help with the indexer you might want to check out our tooling since it is real-time (and can also handle historical data). Let me know if I can set you up with an API key so you can test it. docs.indexing.co

0 reply

0 recast

0 reaction

Ape/rture pfp

If the indexer is lagging you might want to check out our tooling since it is real-time (and can also handle historical data). Let me know if I can set you up with an API key so you can test it. https://docs.indexing.co/

0 reply

0 recast

1 reaction

Ape/rture pfp

Not if you have: 1. Multiple parties using this network 2. Nodes are very very small and cheap compute since they only process a single block 3. Since nodes are small the plan is to tap into excess compute from devices like laptops/phones etc.

0 reply

0 recast

2 reactions

Ape/rture pfp

Or you scale horizontally with a distributed network like we do with The Neighborhood and The Indexing Company

1 reply

0 recast

1 reaction

Ape/rture pfp

We can handle this throughput with The Neighborhood https://neighborhood.indexing.co/ It's all because we do parallel process the data through our network. What helps for storage is filtering before data hits the DBs. For MegaETH specifically you can also chose to use the mini blocks for front-end confirmations, while you chose to use the EVM blocks (1s) to do the data in the DBs. Pipelines can luckily use the same types of filtering.

1 reply

0 recast

0 reaction

Ape/rture pfp

You can use The Indexing Companies public Big Query data set. Big query gives lots of free credits and you can also get other types of FC data. https://console.cloud.google.com/bigquery?sq=867429816176:87fef9a0cc334c199363075701d50e74

0 reply

0 recast

0 reaction

Ape/rture pfp

We are launching The Neighborhood by The Indexing Company, The new solution to fetch on-chain data. This is the first iteration. We are building towards an open distributed network that can process any data, while tapping into excess compute from anywhere. https://neighborhood.indexing.co/

1 reply

1 recast

1 reaction

Brock pfp

@runninyeti.eth

Excited to announce that /indexing has joined Avalanche Codebase to begin protocolizing our infra. The thesis remains simple: - Web1 = my compute - Web2 = their compute - Web3 = our compute While "crypto" has been a clear first use case for these distributed primitives, it certainly won't be the last. Idle compute is *everywhere* and we're on a mission to make it useful. https://x.com/avax/status/1907464995790545090

8 replies

10 recasts

26 reactions

Ape/rture pfp

Are service providers also welcomed? With The Indexing Company we could help with indexing+data infra for both Farcaster and the related on-chain activity. Probably saves you hiring an additional data engineer and reduce setup time to few weeks (vs. few months) Cc: @runninyeti.eth

0 reply

0 recast

1 reaction

Ape/rture pfp

And then to the point that we can do 1-3 at the same time at somepoint. We are developing just In Time Indexing, where you can get any data point or set from any chain at the speed of an API request. We know it's possible with good parallelization because we have done it, it's just a matter of processing power you throw at this problem. Hence why we are building a distributed protocol to do this.

0 reply

0 recast

0 reaction