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

<figure><img src="https://3178759305-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHLL9hGQMOwFm4Txkoliy%2Fuploads%2FtJeEXaSr9E1bmdELUdLh%2Fredstone-logo-full.png?alt=media&#x26;token=7f8010f7-e1b5-4db9-8282-06029e989041" 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;