New features

1. Public canvases and shared queries: Want to share your canvas or a query with someone outside your org? Perhaps they haven't even signed up for sim.io? Just give them a canvas URL or use the share query feature. Anyone can open any canvas link and view its contents in read-only. Anyone can open a shared query link and run that query. The ability to mark a canvas as private, restricting access to org members, is coming soon for our paid tiers.

2. Add new components from handles of existing components: Adding all the new components you need to your canvas using the left sidebar is so yesterday... Instead, click on either handle of any existing component and you'll see a menu of the components that can be connected downstream (or upstream, for the left handle) of the existing component. Click your choice and it's added and automatically connected to the existing node.

   

3. Format SQL: Your SQL is perfect, but your colleague... well... it's not great... Fortunately, there's now a Format SQL feature within the hamburger menu of the query editor.

   

4. New API templates and core tables

   1. Uniswap V3 on-chain prices (X thread)
      1. getPriceFromUniswapV3 and @sim.uniswap_v3_prices
   2. Basenames data (related X threads: 1, 2, 3)
      1. basenames_expiries
      2. basenames_payments
      3. basenames_primary_names
      4. basenames_texts
      5. basenames_reserved
   3. contract_deployments

Coming soon

We're tantalizingly close to solving some major annoyances for users:

1. Table name editing with conflict resolution: You realized there was something you want to improve in your old table but you're using it in production.
2. Clearing schemas and persistences: You wrote some bad/incomplete data into a schema and persistence. There's no shame. We've all done it. But to reset the board, as punishment for your sins, you're going to have to duplicate the existing schema and persistence components as well as the execution edge. Then you delete the originals, reconnect the duplicates, and restart the executions. Don't forget to fix the names! It sucks, especially on bigger canvases with many components flowing into the same persistences. We've decided that the punishment doesn't fit the crime. Instead, we'll give you an option to simply clear the existing schemas and persistences.
3. Complex type support: Sometimes you might want to emit a struct to a schema and have it show up as a JSON in your table. Soon you'll be able to!
4. Cross-lambda shared code: Ever found yourself declaring the same util functions in ten different lambdas of the same canvas. Then you have an idea to improve it and you have to update ten places? Solution coming soon.

New features

1. We have a raft of changes coming to make it easier to share your work and view that of others. The first has already landed: When you're signed in to your org and viewing a canvas from another org, you previously couldn't run test cURLs against the API components because the API key was (correctly) shrouded. Now, however, we're allowing you to test APIs in other canvases with an API key that's specific to your org and works for all API components. This way, you can test other APIs without impacting their org's usage. It's automatic: just use the Copy cURL request feature on an out-of-org canvas and we'll provide the cURL with your org's key. See the coming soon section below for more related changes.
2. Table name editing: A while ago we created table name abstractions / aliases for internal purposes so that we could update and rebuild core tables like @sim.erc20_balance_changes without any downtime for users. Of course, we've heard from you that you want the ability to do the same for your tables! And now you can: simply edit the table name within the persistence component. For now, if you have two tables table1 and table2 and you want to rename table2->table1, you'll have to first rename table1-> any other name to free up the table1 name. Coming soon (see below): a way for you to do both changes in one fell swoop, resulting in no downtime at all.
3. More / better core tables and new API templates
   1. @sim.dex_trades: Normalized DEX trades on Ethereum (Uniswap V2/3, Balancer V2, PancakeSwap V3, Curve.fi) and Base (Uniswap V2/3, Balancer V2, Aerodrome, Infusion, Maverick V1, BaseX, PancakeSwap V3, CrocSwap/Ambient).
   2. @sim.mapping_storage_writes: Changes in values in Solidity mappings in contracts. Includes the real key (hash preimage). Includes Ethereum, Base, and Arbitrum.
   3. @sim.transactions: Summaries of transactions on Ethereum, Base, and Arbitrum.
   4. @sim.blocks: Block summaries. Currently Ethereum only.
   5. getFoia template: Inspired by the Freedom of Information Act, returns all instances in which a user-specified address is included as a key in a mapping.
4. Canvas metadata: Click on the icon at the top of any cavas to see some metadata about it.

5. Patch contract navigation: When you target a contract with the Patch component, we flatten all of the source code into a single file. On most contracts, you can now also navigate to any function or log where you want to include your patch using the Contract navigation feature in the left sidebar. Often it's more efficient that CTRL/CMD-F.

   

Coming soon

Lions and tigers and bears, oh my!

1. If you're not signed in and you visit a canvas, unless it's one of a few of our demo canvases, you're prompted to sign-in before you can view the canvas. Soon anyone will be able to open and view any canvas in read-only mode without signing in. You'll even be able to run test executions on lambdas and test queries in API components. Don't worry--you can't alter the state of someone else's canvas! As always, if you like a canvas, you can sign in, duplicate it into your org ,and modify as you wish. We'll also have more improvements coming to the non-signed-in experience soon.
2. Public org pages: want to know what we're up to in the sim org? All of our canvases our publicly accessible but right now, unless you're in the sim org, you can't see our org dashboard. Soon we'll have public org pages so that you can visit studio.sim.io/sim to see all our org dashboard, regardless of whether you're signed in and what orgs you belong to.
   1. When we introduce paid plans, one feature will be the ability to mark a canvas or an entire org as private so that they're only visible to users within the org. In the meantime, if there's anything you want private, reach out to us on Telegram and we'll do it for you manually (for free 😃).
3. Clearing schemas and persistences: You wrote some bad/incomplete data into a schema and persistence. There's no shame. We've all done it. But to reset the board, as punishment for your sins, you're going to have to duplicate the existing schema and persistence components as well as the execution edge. Then you delete the originals, reconnect the duplicates, and restart the executions. Don't forget to fix the names! It sucks, especially on bigger canvases with many components flowing into the same persistences. We've decided that the punishment doesn't fit the crime. Instead, we'll give you an option to simply clear the existing schemas and persistences.
4. Emit complex types: Sometimes you might want to emit a struct to a schema and have it show up as a JSON in your table. Right now you'd have to emit each member of the struct separately, but soon we'll allow you to emit structs and other complex types directly if you so choose.
5. Table name editing with conflict resolution: I mentioned above that if you want to rename a table with a name that's already taken, you first have to change the name of the conflicting table to free up the name. Soon you'll be able to do these together.

We're launching!

We're thrilled to announce that www.sim.io will be launching publicly tomorrow at 1 p.m. ET, following months of alpha testing and improvements. Your invaluable insights and support have been crucial in getting us here. We're immensely grateful for your time and expertise, especially as we didn’t know many of you before.

We'd greatly appreciate your help once more by asking you to share/quote our announcement Tweet/blogpost on X/Farcaster when it’s posted tomorrow. Your support could significantly boost our reach!

sim has been an incredibly ambitious project, especially for our small team. We've taken some bold steps that set us apart from the current offering and unlock new functionality:

• Our own EVM client optimized for instrumentation and parallel historical execution — at the current state it is already multiple orders of magnitude faster in historical execution than the fastest clients, letting users re-execute entire chains quickly.
• Unparalleled ability to hook, track and decode storage operations, letting you hook, track and understand storage/state changes.
• First EVM (that we know of) that can operate in a cluster and execute different chains simultaneously, allowing us to scale up, support faster backfills for more customers with less hardware.
• Introduction of our EVM Lambda, a serverless EVM Lambda enabling you to seamless interact with on-chain state in an off-chain computation enviorment (currently these off-chain computations are written in solidity, but our goal is to enable any language that compiles down to WASM)
• Bespoke streaming, compute and storage infrastructure that lets you built truly real-time applications
  -Visual IDE and workflows which lets you interact with the most low-level primitives with ease (With time we do intend to support a CLI and declarative code experience in the future)

These innovations allow sim to offer unparalleled capabilities for applications and pipelines that rely on onchain data.In the coming days and weeks, we'll be sharing various examples and tutorials to showcase sim's capabilities.

Thank you again for your continued support. We're excited to see what people will build with sim and how it might transform the ecosystem!

Stateful lambdas

By default, both EVM Lambda and Patch components have their state reset at each block. The benefit of this is it allows for very fast backfills as we can parallelize block execution. In some cases, however, it's really useful to maintain some state across blocks and you only want to run at the tip (or you're patient enough to tolerate sequential backfill). While it's still a very new feature that we're testing and improving, you can now run a stateful lambda. Learn how in our docs. If you're giving it a go, we'd also love to hear from you on Telegram as we're interested in learning more about your use cases.

Canvas locking/unlocking

Most of our sim.io orgs are active construction sites where we're supporting production apps in some canvases and prototyping new ideas in other canvases. If you're not careful, you could accidentally modify an important canvas. To reduce this risk, we've added a canvas locking and unlocking feature in the canvas. You can unlock or lock a canvas from the orgs dashboard or within a canvas (in the top menu). When a canvas is locked, it will render for all users, even those in the org, as a read-only canvas to avoid accidental edits. Want to make an edit? Just unlock it, make your edit, and lock it once more.

New features

1. Patched contracts: You can now customize blockchain executions by directly modifying an existing contract with the Patch component. Patch complements our existing EVM Lambda component, in which you define the code you want to execute on-chain as well as hooks that determine when that code executes. With a patched contract, whenever execution would have involved the contract that you patched, we swap in your patched contract instead. For many purposes, from emitting a little extra data to performing complex simulations, either component can be used. For both, state is reset at the end of the block (more on that below!) to enable parallelization for lightning-fast backfills. So which should you use?

   1. Lambdas are more flexible: You can insert execution across many contracts (e.g., that share an ABI), or upon each transaction, or each storage write, or each block, etc. None of these is possible with Patch.
   2. Patch puts you within the contract: If you're interested in a single contract, and particularly if you'd like to emit transient values from it, Patch is very powerful.

   When you choose which contract you want to patch, we automatically flatten all of the source code, similarly to the evm.codes contract viewer. As you make edits, toggle on Show diff to see the diff between the patched contract and the original. Test in the IDE and deploy a backfill via connecting to a data source, just like the Lambda. For more on Patch, check out our docs and try one yourself.

2. Multichain tables/APIs: Our core tables and API templates are now multichain. You'll see chain_id as a column in most tables. For the API templates, it's often an optional parameter--if you want to execute the requests across chains, no worries--just leave the default chain_id = 0 and we won't filter on chain.

Coming soon

1. Stateful probes (as discussed last changelog)
2. alpha -> beta + public launch (as discussed last changelog)

New features

1. Auto-generated schemas: When you're adding a hook in a lambda, you can choose to automatically generate and populate a corresponding schema. This means your lambdas will be fully testable, and in some cases ready to be deployed for backfills, without you having to write any Solidity at all.

2. Schema mirrors: You can now mirror data from a sim schema component into your own Generic Kafka or Confluent Cloud topic. Create the destination topic first, then create a new Schema mirror component in you canvas, connect it to an existing schema component, and point it at the destination topic.

3. API templates: We've been building core tables to make it easier for you to serve common query/API patterns without having to build the data yourself in a lambda. We're now going further in this direction by providing API templates on top of them. When defining an API query, explore the templates via the sidebar, run them, and choose Use this template as API to insert a template into the API Query tab. If it's exactly what you want, great. If not, customize it to your specific requirements.

4. Block filters for faster backfill: Sometimes when you do a backfill execution for your lambda, there are very few blocks within the block range in which the hooks actually intercept executions. Previously we'd still execute all blocks in the block range despite this, but now we have filters so that we'll only execute blocks relevant to your lambda. As a result, backfills are much faster, especially on sparser hooks. We're still improving how the filters work for more active contracts.

Improvements and bug fixes

1. You can now manually define the API key for API components, both at initial setup and in subsequent edits.
2. Query params used to reset whenever the query was changed at all, and when execution of the query failed. We've made them much stickier.

Coming soon

1. Open alpha: We're preparing to remove the waitlist and move to an open alpha. We'll be limiting certain features for new users. As part of this effort, we're also beefing up our execution and DB infra, which should result in a more performant and consistent experience for existing users.
2. Stateful lambdas: Currently any state you generate within a lambda gets reset every block. This is usually very nice as it means we can safely parallelize backfills, and aggregations can be done downstream or at query time. For some use cases, however, calculating and adjusting aggregations across blocks within the lambda’s state is very powerful, so we're launching a stateful version of the EVM lambda in the near future. These may be more costly to run and won’t backfill as fast, but they're extremely powerful for specific use cases.
3. A new patched contract component (as mentioned last changelog).

New features

1. When you add an address hook, you can now manually define and edit the associated ABI. This is handy for cases where we don't have the ABI (e.g., it's unverified) but you do, as well as when you want to edit/override the ABI that we have for the inputted address.

2. When you add an interface, you can also now input an ABI directly. You can input an entire ABI or just the functions you need. Interfaces can also always be renamed and edited in the Interface code tab.

3. We now support Base Sepolia. We don't fetch Sepolia contracts, so it's a BYOABI (bring-your-own ABI) situation for address hooks. Aside from that caveat, all hook types should work as they do on other chains.

Coming soon

1. A productized approach to schema mirroring, allowing you to ingest sim data into your own DBs. We're already doing this manually for some users, so reach out if you'd benefit from it.
2. API templates. We want to make it easy for everyone to replicate third-party endpoints they already use directly in sim. Want to get an account's NFT portfolio or see a token's holder leaderboard? No need to start from scratch, as we'll have in-product templates ready to use/edit/augment.
3. A new Patch component. Some uses cases (e.g., extracting transient values) can be hard to do with the EVM lambda. To better handle these, we're adding a new component that allows you to run a patched version of a contract. Within the patched contract, you're still able to execute custom logic and emit data to schemas, just as you do in the EVM lambda. We recommend the EVM lambda whenever possible as it's more flexible, capable and extensible, but the new component will be helpful for some use cases.

Bug fixes

1. In the canvas, we were showing incorrect addresses for address hooks in the EVM lambda component. This is now fixed.
2. Adding an interface sometimes introduced compiler errors. We believe we've now fixed this universally.
3. The query editor was showing all org queries instead of just your own. No longer.

EVM lambda redesign

We've rebuilt the EVM lambda component to make it both simpler and more functional. It includes:

1. A unified sidebar to manage hooks, schemas, and interfaces.
2. The ability to connect and edit an existing schema or create a new one without leaving the component.
3. A more linear flow from hook definition through to testing, combined with richer inline documentation.

Here's a walk-through of the changes:

Bug fixes

1. Fixed bug where transaction hooks against different addresses within the same lambda would overwrite one another.
2. Fixed bug where you could only add evm.storage variable hooks if you also hooked on the contract of the variable.

Coming soon

1. A feature that allows you to manually input the ABI of an unverified contract, or a verified one that we haven't yet fetched, to enable function and log hooks.
2. We've heard from users that support for Base Sepolia would be helpful. Working on it. Initial support will be limited, won't include contract fetching.
3. A productized approach to schema mirroring, allowing you to ingest sim data into your own DBs. We're already doing this manually for some users, so reach out if you'd benefit from it.

Improvements and new features

1. Core tables, backfilled and updating at the tip! We're continuing to improve ergonomics, add sample queries, and validate, but we'd love for you to start using them for analysis or APIs:

   1. @sim.ethereum_erc20_balance_changes
   2. @sim.ethereum_erc20_allowance_changes
   3. @sim.ethereum_erc721_owner_changes
   4. @sim.ethereum_erc721_approval_changes
   5. @sim.ethereum_mapping_storage_writes
   6. @sim.base_dex_trades

2. You can now duplicate a canvas (from any org) into your own org. All of the canvas state carries over. You can edit the duplicated canvas as you wish to run your own executions, populate persistences, etc.

   

3. Ever wished you could use sim to instrument your data but still keep things in the confines of your own infrastructure? Well, wish no more! You can now mirror your schemas to an external Kafka with minimal latency. This handy feature will soon be available as a self-serve component in your canvases. For now, if you have a schema you'd like to mirror, just give us a shout and we'll get it set up in a matter of minutes!

4. Query editor now shows query execution metadata and paginates results.

   

5. Some more minor changes:

   1. Schema functions in the EVM lambda component now define their messages in a struct. This allows you to include arbitrarily many columns--previously it was capped at 16. It also makes the messages a bit more explicit, and makes the ordering more flexible.

   2. 

      EVM lambda test interactions now show results in more interpretable types, e.g., decimal representation for integers.

   3. When you edit the name of an interface in the Interface code tab of the code editor, the new name will show up in the sidebar for later reference.

   4. You can expand the width of components in the canvas by dragging from their right edge.

Bug fixes

1. Sometimes a "run" interaction in the query editor would run an older version of the query due to a race condition between the saving and execution. This is now fixed.
2. Coverage of Base and Arbitrum was limited for address (and import ABI via address) hooks. We refetched contracts to fix this.

Coming soon

1. Based on your feedback, we're working on a simplified, more focused EVM lambda component. It'll also allow you to edit and create schemas within the EVM lambda component. Here's a sneak preview:

2. More core tables:
   1. Block, transaction, and DEX tables for Ethereum
   2. ERC20, 721, and mapping storage writes tables for Base

Improvements

1. Base and Arbitrum: you can now run EVM lambdas on them!
   1. Backfills on Base and Arbitrum may be a little slower while we tune them.
   2. Source code backfills are ongoing, so storage tracking and ABI hooking might be limited for some contracts. If you run into this, let us know and we can manually add the contract.
   3. Arbitrum support starts at block 22207818, the block after Arbitrum Nitro genesis.
2. New query and API experience makes querying your data and building APIs much easier.
   1. Instead of writing SQL queries in small input boxes in your canvas, we've broken it out to a dedicated query editor. It has autocomplete and renders results in a table.
   2. Before, an API node's query was defined in a connected Query node. We've instead put the query definition directly in the API component, and deprecated the old query node.
3. Onboarding: You'll notice more helpful tips around the canvas and below components. If you close these, they won't reappear unless you reset your browser's local storage. You can open each component's quick guide at any time in its action menu.

Announcements

1. We've added a few demo canvases to the org dashboard screen as well our new marketing site, sim.io. They're also documented in our documentation hub: docs.sim.io.
2. We're continuously expanding our closed alpha to new users. If you know of any folks that might benefit from the tool, please put us in touch!