> For the complete documentation index, see [llms.txt](https://zenofchain.gitbook.io/redstone-quick-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zenofchain.gitbook.io/redstone-quick-guide/articles/redstones-other-parts-aggregation-and-safety-and-others.md).

# RedStone's other parts:aggregation & safety and others

<figure><img src="/files/XXZvEBvAHN8Z3BeaDA2O" alt=""><figcaption></figcaption></figure>

The RedStone oracle system utilizes an on-chain aggregation mechanism to enhance the security of data feeds. This on-chain aggregation requires that a minimum threshold of signatures from different authorized data providers must be passed before a data feed can be returned to a consumer contract.&#x20;

The way it works is that the values from all of the authorized providers for a particular data feed are aggregated together before being returned to the consuming contract. Typically, a median value calculation is used to aggregate the values. By aggregating from multiple providers, even if a small subset of providers submit corrupt data, it will not significantly impact the aggregated value.&#x20;

There are several key **on-chain aggregation** parameters configured in the RedStone consumer base contract:

* `getUniqueSignersThreshold` function - This sets the minimum number of unique signer signatures required before a data feed can be returned.
* `getAuthorizedSignerIndex` function - This whitelist contains the indexes of the authorized data providers.
* `aggregateValues` function - Used to aggregate numeric 256-bit values. Computes the median of all values.
* `aggregateByteValues` function - Used to aggregate dynamic byte arrays. Concatenates the byte arrays.&#x20;

RedStone supports **two data types** that can be returned in the data feeds:

* 256-bit Numeric Values - This is the default data type, used for numeric data.
* Dynamic Byte Arrays - Used when binary data needs to be returned.&#x20;

Some **security considerations** when using RedStone:

* Do not override the getUniqueSignersThreshold unless certain the new value is secure.
* Pay close attention to timestamp validation logic to avoid arbitrage attacks.
* Enable secure upgradability for consumer contracts through multi-sig or DAO.
* Monitor the data provider registry for changes and update authorizations.&#x20;

(actually it seems that all could be well-handled IMAO so no worries really lol)

**Recommendations** when using RedStone:

* Design contracts to minimize data feeds per transaction.
* Use approximately 10 required unique signers for a good balance of security and efficiency.
* Cache latest values in storage to avoid having to retrieve duplicate feeds.&#x20;