Full proposal: [https://index.acuity.network/proposals/2/](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`](https://docs.rs/subxt/0.43.0/subxt/attr.subxt.html) macro by calling [EventDetails::as\_root\_event()](https://docs.rs/subxt/0.43.0/subxt/events/struct.EventDetails.html#method.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()](https://docs.rs/subxt/0.43.0/subxt/events/struct.EventDetails.html#method.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/](https://index.acuity.network/proposals/2/)

Pinkdrop, a popular casual browser game in the Polkadot ecosystem, seeks funding to expand its features with a mobile app and on-chain tournaments. Developed by the Great Escape team, Pinkdrop merges Parachain balls strategically to accumulate points. The proposal aims to enhance user engagement and attract new users to Polkadot by making the game more accessible and exciting.

Accounting software integration.

Wallet connect integration.

NFT Support.

Treasury Analytics Dashboard.

Technical Improvements & SDK updates.

Repeat Batch transactions and transfers.

Polkadot Vault & Ledger Support.

Invoices.

XCM Transfers.

On-Off ramp support.

In-app chat.

Apps.

Link Multiple pure-proxies.

Dashboard.

Tips.

Watchlist.

Propose and approve a spend of treasury funds.

## Dispatch Origin

Must be [`Config::SpendOrigin`] with the `Success` value being at least `amount`.

### Details
NOTE: For record-keeping purposes, the proposer is deemed to be equivalent to the
beneficiary.

### Parameters
- `amount`: The amount to be transferred from the treasury to the `beneficiary`.
- `beneficiary`: The destination account for the transfer.

## Events

Emits [`Event::SpendApproved`] if successful.

Acuity Index: omni-indexer

Democracy

#567 Acuity Index: omni-indexer

No Active Proposals