You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the aztec node is currently storing logs, and allow querying on a few properties, we don't have something like the indexed which is usual to see on EVM chains.
This is often used for frontends or the like, for example to look for transfer events that are important to the user, instead of looking at all the transfer events.
This is currently unsupported, and I think it should be considered for implementation. It seems fairly straight forward to implement a version where filtering on values is possible at the receiving end, but that seems wasteful, no need to provide us with all the logs if we are just instantly throwing half away.
For now I think we can do similar to what we allowed for private events, e.g., split the getEvents into a getPrivateEvents and a getPublicEvents and get a hold of either.
The text was updated successfully, but these errors were encountered:
While the aztec node is currently storing logs, and allow querying on a few properties, we don't have something like the
indexed
which is usual to see on EVM chains.This is often used for frontends or the like, for example to look for transfer events that are important to the user, instead of looking at all the transfer events.
This is currently unsupported, and I think it should be considered for implementation. It seems fairly straight forward to implement a version where filtering on values is possible at the receiving end, but that seems wasteful, no need to provide us with all the logs if we are just instantly throwing half away.
For now I think we can do similar to what we allowed for private events, e.g., split the
getEvents
into agetPrivateEvents
and agetPublicEvents
and get a hold of either.The text was updated successfully, but these errors were encountered: