Researching Chainlink contracts can be little confusing, especially if you flip between Etherscan, market.link and other explorers. Unfortunately, contract types are often listed differently by different projects.
So, I thought I’d put together a quick overview of the current Chainlink aggregator contract types as listed on market.link and compare them to theie equivalent Etherscan listings.
market.link abbreviation
market.link contract name
Etherscan contract name
AG
Aggregator
Aggregator
FL
Flux Aggregator
AccessControlledAggregator
OCR
Offchain Aggregator
AccessControlledOffchainAggregator
AG – market.link
FL – market.link
OCR – market.link
Thanks for making this topic, it helped me to understand a bit better the different types of aggregators, also the FL Aggregators: “The Technical Explanation” were quite useful as well
What would be the difference -if any- between Flux Aggregators and regular aggregators? If I understood it correctly Flux Aggregators are the same as AccessControledAggregators (ACA contracts) (?)
I’m still trying to wrap my head around this. ACA contracts are those that instead of paying the nodes by airdropping each time they send data allow the nodes to withdraw the LINK owed to them whenever the nodes want, right?
Yes, you are correct, these are the main difference between each aggregator contract implementation.
The Aggregator.sol contract was the first Chainlink reference contract (launched during mainnet in may 2019) which was powered by Chainlink nodes running the RunLog client. This is where every price feed update involved a requester address making a transaction that generated a LINK token transfer to each node. This was an expensive implementation as token transfers are not cheap.
The AccessControlledAggregator.sol (FluxAggregator) contract was the second version (released summer 2020) powered by Chainlink nodes running the FluxMonitor client. This contract was a large improvement as it removed the requester all together. Instead nodes themselves would monitor when updates were needed. After pushing their data on-chain during an update, nodes would be allocated LINK tokens, incrementing their internal balance within the contract for which they could withdraw at any time. This was far cheaper as LINK token transfers only occur during withdraws which are rare.
The AccessControlledOffchainAggregator.sol (Off-Chain Reporting) contract is the latest version (rolling out to mainnet soon) powered by Chainlink nodes running the OCR client. This follows the FluxMonitor where there is no requester and tokens are allocated per update, but improves upon it by batching node responses per update into a single transaction.
That is a really clear and concise answer. I’d say I understand the main differences between the different contract implementations now. I really appreciate it CLG!
Cheers CLG, we appreciate you stopping by to say hello and drop some knowledge!
This contract was a large improvement as it removed the requester all together. Instead nodes themselves would monitor when updates were needed. After pushing their data on-chain during an update, nodes would be allocated LINK tokens, incrementing their internal balance within the contract for which they could withdraw at any time. This was far cheaper as LINK token transfers only occur during withdraws which are rare.
This change brought some significant gas savings, I’m looking forward to some longer-term OCR stats, the initial numbers are encouraging
