Acuity Index: omni-indexer

16d ago

Rejected

Content

AI Summary

Full proposal: https://index.acuity.network/proposals/2/

Currently Acuity Index works by decoding each event into a Rust type that has been generated automatically by the subxt macro by calling EventDetails::as_root_event()

This has a number of problems. Currently event types are only derived for the latest runtime for each chain. If events have been modified or removed during chain upgrades the latest version of the indexer may not be able to index certain events from older blocks.

One solution to this would be to derive event types and maintain indexing macros for all runtimes that a chain has had. The burden of maintaining the indexer for each chain would be large and complex.

During build the subxt macro is extremely slow and requires a considerable amount of RAM. Running it for every individual runtime would increase the build requirements considerably making maintenance even harder.

Converting the event into dedicated types also increases the CPU time required during indexing.

Consumers of the index (dapps) typically will not want to decode events into runtime-specific types. This would add to the complexity and maintenance burden of the dapp.

It is unusual for the schema of an individual event to change over a runtime upgrade. Typically events are added or removed.

A much better approach is to call EventDetails::field_values()

This has a number of advantages:

separate indexers do not need to be built for each chain
macros do not need to be written for custom pallets
chain indexing can be specified in a simple TOML file
a single specification can handle indexing all of a chain's runtime versions
decoded parameters for each individual event can be stored and returned in query results

A chain index specification will include the following config items:

name
genesis hash
list of block numbers where index updates have occured - re-indexing will occur as necessary upon upgrade of Acuity Index or index specification
default full node url
Polkadot SDK version - Acuity Index must be updated to support it
for each current or historic pallet either specify:
- default for Polkadot SDK built-in pallets
- custom for each event variant specify which parameters should be indexed by which key

Full proposal: https://index.acuity.network/proposals/2/

Edited

Request

256KSM

Status

Decision14d

Confirmation

12hrs

Attempts

Tally

37.7%Aye

50.0%Threshold

62.3%Nay

Aye

≈128.02KKSM

Nay

≈211.25KKSM

0.0%
0.0%
Threshold
0.0%

Support

0.16%

≈26.47KKSM

Issuance

≈16.35MKSM

Votes

Nested

Flattened

Actions

Check how referenda works here.

Call

Metadata

Timeline4

Votes Bubble

Curves

Statistics

Comments

Cb3Z...XkGY

If events have been modified or removed during chain upgrades the latest version of the indexer may not be able to index certain events from older blocks.

I wonder, did I not mention this exact situation in my unanswered comment on your previous proposal?

kukabi | Helikon

DaCS...Liax

PolkaWorld Vote: AYE

The budget for such a critical infrastructure project is reasonable, and the deliverables (to be completed by August 2025) are clearly defined and measurable. If widely adopted, Acuity Index will enable wallets, block explorers, DeFi applications, and even future JAM-based dapps to operate without relying on centralized backends — a crucial step forward for Polkadot’s long-term decentralization narrative.

We also suggest the team produce detailed technical documentation and tutorials after delivery to ensure seamless integration for developers.

👉 See the full feedback here.

Fa6m...wiBr

Dear Proposer,

Thank you for your proposal. Our first vote on this proposal is NAY.

The Small Spender track requires 50% participation and simple majority of non-abstain votes according to our voting policy v0.2, and any referendum in which the majority of members vote abstain receives an abstain vote. This proposal has received zero aye and four nay votes from ten available members, with one member abstaining. Below is a summary of our members' comments:

The referendum proposed a significant change to Acuity Index’s event decoding method by shifting from generating Rust types to using field_values(), which promised easier maintenance and broader runtime support. However, the proposal faced strong criticism for technical shortcomings and a lack of clarity regarding its necessity and application. Several comments pointed out previous issues that had not been adequately addressed and expressed skepticism about the team’s grasp of Substrate storage and runtime upgrades. While some questioned the technical details and practical demand from dapps, one voter noted hesitation. Ultimately, these concerns drove the decision to vote against the proposal.

The full discussion can be found in our internal voting.

Please feel free to contact us through the links below for further discussion.

Kind regards,
Permanence DAO
Decentralized Voices Cohort IV Delegate

📅 Book Office Hours
💬 Public Telegram
🌐️ Web
🐦 Twitter
🗳️ Delegate