profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/RodrigoAD/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Rodrigo Ariza RodrigoAD Bonn, Germany

RodrigoAD/react_cryptocurrencies 3

Simple React App showing main crypto prices

RodrigoAD/meteor_voting_dapp 2

Meteor Simple Dapp running in Ethereum Blockchain

cherrerog/P4 0

Práctica 4. ISI

RodrigoAD/ethereum_voting_dapp 0

Simple Ethereum Voting dapp using Truffle framework

RodrigoAD/GoogleDoc2Html 0

Export Google Doc as clean html. Handy to make a Wordpress post from Google Doc.

RodrigoAD/mattermost-server 0

Open source Slack-alternative in Golang and React - Mattermost

RodrigoAD/token_pool_webapp 0

Simple Token Pool Web App

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsmartcontractkit/chainlink

ArbitrumValidator.sol - fix withdrawFundsFromL2 msg encoding

 contract ArbitrumValidator is TypeAndVersionInterface, AggregatorValidatorInterf   address constant ARBSYS_ADDR = address(0x0000000000000000000000000000000000000064);    /// @dev Follows: https://eips.ethereum.org/EIPS/eip-1967-  address private constant FLAG_ARBITRUM_SEQ_OFFLINE =+  address public constant FLAG_ARBITRUM_SEQ_OFFLINE =

Yeah better

krebernisak

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsmartcontractkit/chainlink

L2 Emergency Protocol (Arbitrum) update

 contract ArbitrumValidator is TypeAndVersionInterface, AggregatorValidatorInterf       return true;     } -    int isServiceOffline = 1;-    // NOTICE: if gasCostL2 is zero the payment is processed on L2 so the L2 address needs to be funded, as it will-    // paying the fee. We also ignore the returned msg number, that can be queried via the InboxMessageDelivered event.-    s_inbox.createRetryableTicket{value: s_gasConfig.gasCostL2}(-      s_l2FlagsAddress,+    // Excess gas on L2 will be sent to the L2 xDomain alias address of this contract+    address refundAddr = L2_ALIAS;+    // Encode the Forwarder call+    bytes4 selector = ForwarderInterface.forward.selector;+    address target = L2_FLAGS;+    // Choose and encode the underlying Flags call+    bytes memory data = currentAnswer == ANSWER_SEQ_OFFLINE ? CALL_RAISE_FLAG : CALL_LOWER_FLAG;+    bytes memory message = abi.encodeWithSelector(selector, target, data);+    // Make the xDomain call+    // NOTICE: We approximate the max submission cost of sending a retryable tx with specific calldata length.+    uint256 maxSubmissionCost = _approximateMaxSubmissionCost(message.length);+    uint256 maxGas = s_gasConfig.maxGas;+    uint256 gasPriceBid = s_gasConfig.gasPriceBid;+    uint256 l1PaymentValue = s_paymentStrategy == PaymentStrategy.L1 ? _maxRetryableTicketCost(maxSubmissionCost, maxGas, gasPriceBid) : 0;+    // NOTICE: In the case of PaymentStrategy.L2 the L2 xDomain alias address needs to be funded, as it will be paying the fee.+    // We also ignore the returned msg number, that can be queried via the `InboxMessageDelivered` event.+    IInbox(CROSS_DOMAIN_MESSENGER).createRetryableTicketNoRefundAliasRewrite{value: l1PaymentValue}(+      L2_CROSS_DOMAIN_FORWARDER, // target       0, // L2 call value-      // NOTICE: maxSubmissionCost info will possibly become available on L1 after the London fork. At that time this-      // contract could start querying/calculating it directly so we wouldn't need to configure it statically. On L2 this-      // info is available via `ArbRetryableTx.getSubmissionPrice`.-      s_gasConfig.maxSubmissionCost, // Max submission cost of sending data length-      s_gasConfig.refundableAddress, // excessFeeRefundAddress-      s_gasConfig.refundableAddress, // callValueRefundAddress-      s_gasConfig.gasLimitL2,-      s_gasConfig.maxGasPrice,-      currentAnswer == isServiceOffline ? CALL_RAISE_FLAG : CALL_LOWER_FLAG+      maxSubmissionCost,+      refundAddr, // excessFeeRefundAddress+      refundAddr, // callValueRefundAddress+      maxGas,+      gasPriceBid,+      message     );+    // return success

The only case I was thinking it was tracking the message, but InboxMessageDelivered does it already then

krebernisak

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsmartcontractkit/chainlink

L2 Emergency Protocol (Arbitrum) update

 contract ArbitrumValidator is TypeAndVersionInterface, AggregatorValidatorInterf       return true;     } -    int isServiceOffline = 1;-    // NOTICE: if gasCostL2 is zero the payment is processed on L2 so the L2 address needs to be funded, as it will-    // paying the fee. We also ignore the returned msg number, that can be queried via the InboxMessageDelivered event.-    s_inbox.createRetryableTicket{value: s_gasConfig.gasCostL2}(-      s_l2FlagsAddress,+    // Excess gas on L2 will be sent to the L2 xDomain alias address of this contract+    address refundAddr = L2_ALIAS;+    // Encode the Forwarder call+    bytes4 selector = ForwarderInterface.forward.selector;+    address target = L2_FLAGS;+    // Choose and encode the underlying Flags call+    bytes memory data = currentAnswer == ANSWER_SEQ_OFFLINE ? CALL_RAISE_FLAG : CALL_LOWER_FLAG;+    bytes memory message = abi.encodeWithSelector(selector, target, data);+    // Make the xDomain call+    // NOTICE: We approximate the max submission cost of sending a retryable tx with specific calldata length.+    uint256 maxSubmissionCost = _approximateMaxSubmissionCost(message.length);+    uint256 maxGas = s_gasConfig.maxGas;+    uint256 gasPriceBid = s_gasConfig.gasPriceBid;+    uint256 l1PaymentValue = s_paymentStrategy == PaymentStrategy.L1 ? _maxRetryableTicketCost(maxSubmissionCost, maxGas, gasPriceBid) : 0;+    // NOTICE: In the case of PaymentStrategy.L2 the L2 xDomain alias address needs to be funded, as it will be paying the fee.+    // We also ignore the returned msg number, that can be queried via the `InboxMessageDelivered` event.+    IInbox(CROSS_DOMAIN_MESSENGER).createRetryableTicketNoRefundAliasRewrite{value: l1PaymentValue}(+      L2_CROSS_DOMAIN_FORWARDER, // target       0, // L2 call value-      // NOTICE: maxSubmissionCost info will possibly become available on L1 after the London fork. At that time this-      // contract could start querying/calculating it directly so we wouldn't need to configure it statically. On L2 this-      // info is available via `ArbRetryableTx.getSubmissionPrice`.-      s_gasConfig.maxSubmissionCost, // Max submission cost of sending data length-      s_gasConfig.refundableAddress, // excessFeeRefundAddress-      s_gasConfig.refundableAddress, // callValueRefundAddress-      s_gasConfig.gasLimitL2,-      s_gasConfig.maxGasPrice,-      currentAnswer == isServiceOffline ? CALL_RAISE_FLAG : CALL_LOWER_FLAG+      maxSubmissionCost,+      refundAddr, // excessFeeRefundAddress+      refundAddr, // callValueRefundAddress+      maxGas,+      gasPriceBid,+      message     );+    // return success

Would an event be useful here? As on withdrawFundsFromL2 with emit L2WithdrawalRequested(id, amount, refundAddr);

krebernisak

comment created time in 7 days

starteddanielduarte/flowed

started time in 9 days

Pull request review commentsmartcontractkit/chainlink

L2 Emergency Protocol (Arbitrum) update

 contract ArbitrumValidator is TypeAndVersionInterface, AggregatorValidatorInterf       return true;     } +    // Excess gas on L2 will be sent to the L2 xDomain alias address of this contract+    address refundAddr = AddressAliasHelper.applyL1ToL2Alias(address(this));

Would be nice to have some way to inspect this address now that is not on GasConfig. As it's a constant now, could we do the same as other constants and make it address immutable public?

krebernisak

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentsmartcontractkit/chainlink

L2 Emergency Protocol (Arbitrum) update

 contract ArbitrumValidator is TypeAndVersionInterface, AggregatorValidatorInterf       return true;     } +    // Excess gas on L2 will be sent to the L2 xDomain alias address of this contract+    address refundAddr = AddressAliasHelper.applyL1ToL2Alias(address(this));

At the end we are doing what createRetryableTicket does for us. If refundAddr will always be this contract aliased, we can let Arbitrum do the aliasing for us

krebernisak

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentsmartcontractkit/chainlink

L2 Emergency Protocol (Arbitrum) update

 contract ArbitrumValidator is TypeAndVersionInterface, AggregatorValidatorInterf       return true;     } -    int isServiceOffline = 1;-    // NOTICE: if gasCostL2 is zero the payment is processed on L2 so the L2 address needs to be funded, as it will+    // Encode the Forwarder call+    bytes4 selector = ForwarderInterface.forward.selector;+    address target = L2_FLAGS;+    // Choose and encode the underlying Flags call+    bytes memory data = currentAnswer == ANSWER_SEQ_OFFLINE ? CALL_RAISE_FLAG : CALL_LOWER_FLAG;+    bytes memory message = abi.encodeWithSelector(selector, target, data);+    // Make the xDomain call+    // NOTICE: if gasCostL2Value is zero the payment is processed on L2 so the L2 address needs to be funded, as it will     // paying the fee. We also ignore the returned msg number, that can be queried via the InboxMessageDelivered event.-    s_inbox.createRetryableTicket{value: s_gasConfig.gasCostL2}(-      s_l2FlagsAddress,+    IInbox(CROSS_DOMAIN_MESSENGER).createRetryableTicketNoRefundAliasRewrite{value: s_gasConfig.gasCostL2Value}(

createRetryableTicketNoRefundAliasRewrite I imagine doesn't change refundAddr address to the new L2 alias right?

krebernisak

comment created time in 18 days

PullRequestReviewEvent

push eventsmartcontractkit/external-adapters-js

Rodrigo Ariza

commit sha e84d9fb69d72fc9f64a673b498373b9f7c30d35b

feat: added expected errors for optimism empty txs (#805)

view details

push time in a month

delete branch smartcontractkit/external-adapters-js

delete branch : layer-2-optimism-config

delete time in a month

create barnchsmartcontractkit/external-adapters-js

branch : layer-2-optimism-config

created branch time in a month

push eventsmartcontractkit/chainlink

Sam

commit sha 7a59944ce3cb539263b36b03e0c9a92489fce472

Refactor Config into General/EVM-specific (#4840) This is a necessary pre-requisite to splitting the configs for multichain. Brief summary of changes: - Config is now an exported interface from config package. Concrete structs are not used by the application. - Tests now use a dedicated test config struct that implements the application config interface. Overrides are made explicitly by setting fields on the Overrides struct in the test config. If an override is not set, it falls back to the normal application config. This is a more flexible, explicit and powerful way of managing config than our old system of clobbering the global object. - Application-wide config is separated from chain-specific config (GeneralConfig vs EVMConfig) - Config interfaces are used more broadly in consuming packages (this should be encouraged for all new config consumers) - Removal of orm.ConfigReader - Complete overhaul and simplification of how we are using config in tests - Preparing ground for chain-scoped EVMConfig

view details

Piotr Trzpil

commit sha 50fec81e1cf4ae59c4097cbff335b57563dbd09c

Handle Gas Estimator failure on start (#4850) * fix case where gas estimator fails estimation on start

view details

Roman Behma

commit sha 3ddc82598abe2f4fd2e374473f89083dbce11c1c

Store the bootstrap multiaddrs on a job proposal (#4841) * Added a logic to store bootstrap multiaddrs coming from FMS * updated proto files * fixed test * accept multiaddr only for OCR jobs * fixed tests * fixed tests * fixed tests

view details

James Kong

commit sha 49b0d8c95c221e67ce96b35128e9c4097cd88019

Show the connected status of a feeds manager (#4844)

view details

Piotr Trzpil

commit sha f4d3779117ff7b060e33309ef436f81287e3b578

Hibernation ticker instead of timer (#4848) * hibernation ticker instead of timer

view details

dependabot[bot]

commit sha 9370111534568b750a0e550520b833fa0dab6a3f

Bump path-parse from 1.0.6 to 1.0.7 (#4851) Bumps [path-parse](https://github.com/jbgutierrez/path-parse) from 1.0.6 to 1.0.7. - [Release notes](https://github.com/jbgutierrez/path-parse/releases) - [Commits](https://github.com/jbgutierrez/path-parse/commits/v1.0.7) --- updated-dependencies: - dependency-name: path-parse dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>

view details

Connor Stein

commit sha 016d568246bb9646d5742ef439c7ae1998c33751

Accept integer thresholds for FMv2 specs (#4845) Accept integer thresholds for FMv2 specs

view details

Connor Stein

commit sha af941205d6ab78ec2335b1214f4d4bb4e7d62a1a

Fallback to max gas limit in estimategas (#4853) Fallback to max gas limit

view details

Blaž Hrastnik

commit sha 57c1ac11cd35f928b6b20c51cc8d84d3d3c419db

Pipeline task retry (#4835) * utils/http: Strip out retries, simplify DefaultTransport & MaxBytesReader Both of these are doable using stdlib nowadays. * Disable lint that was enabled by accident * Generic task retry mechanism * Fix failEarly test case * Try disabling retries? * Disable default retries on HTTP, make it completely opt-in

view details

Rodrigo Ariza

commit sha e17e84b0e22d6c315db1f23128bddd3f84854d81

Merge branch 'develop' into arbitrum-flag-validator

view details

push time in a month

push eventsmartcontractkit/chainlink

James Kong

commit sha ae1367196409ffd485d76a817b8bd0aee3662845

Report node version (#4834) * Extract Node Version ORM from store into it’s own service package * Report the current node version to FMS * Move FindLatestNodeVersion error handling up to the caller

view details

Connor Stein

commit sha 76c7b47be8e3d32a318de84b9590639c26106a57

VRF v2: VRFCoordinatorV2 implementation (#4526) - New v0.8 Contracts for the V2 VRF: `VRFCoordinatorV2.sol`, `VRF.sol`, `VRFConsumerBaseV2.sol`, `VRFCoordinatorV2Interface.sol` - Related test contract `VRFConsumerV2.sol` and example contracts `VRFSingleConsumerExample.sol` and `VRFConsumerExternalSubOwnerExampl.sol` - New vrfv2 and estimategas task types - The vrf delegate now detects which task type is present and returns a v1 or v2 vrf listener depending on that - Typescript test coverage for all aspects of VRFCoordinatorV2.sol except for the fulfillment, which is tested in integration_v2_test.go

view details

Piotr Trzpil

commit sha 13533d5da10d1e3b2e02f493c583251db179f882

Fix Lock_withLock flakiness (#4842)

view details

Piotr Trzpil

commit sha 18e43242e8a8be694187a6c5b19c3d9fc275054f

increase no-heads warning threshold to 1m on optimism (#4838)

view details

Piotr Trzpil

commit sha ae6e74d2ddaa924ec284e089443db405b586b20a

Fix lock timeout usage in pg lock (#4847)

view details

James Kong

commit sha 9dca18bfe792a16192f3f3ce76024beecb24ecd8

Add a features flags endpoint to the API

view details

James Kong

commit sha f22d6ba56faf642d49eb3651e7a4469f3d261ee0

Show/Hide features in the UI based on feature flags

view details

John Barker

commit sha c32204cfb61c3b8e00135829ee1f0a97cd010fe4

Merge branch 'develop' into feature-flags

view details

John Barker

commit sha 737e95427726fb560f8efd3cf9efe64106612575

Merge pull request #4843 from smartcontractkit/feature-flags Add feature flags to toggle features in the UI

view details

Sam

commit sha 631167bcc78d85a2323ba8685c7b7a4239d0b638

Fix handling of nil values for gas price (#4849)

view details

Rodrigo Ariza

commit sha 6423d4b249f2da52979bda89573258c13ad37fc1

Merge branch 'develop' into arbitrum-flag-validator

view details

push time in a month

Pull request review commentsmartcontractkit/documentation

add l2 sequence health flag

+---+layout: nodes.liquid+date: Last Modified+title: "L2 Sequencer Health Flag Docs"+permalink: "docs/l2-sequencer-flag/"+---++The idea behind an Optimistic Rollup (OR) type of protocol is to move all execution off-chain and keep all transaction data available on-chain. Such protocols have a special off-chain component, a Sequencer, that executes and rolls up the Layer 2 transactions by batching multiple transactions into a single one.++If a sequencer becomes unavailable, it becomes impossible to access read/write APIs that consumers are using so every dapp will be down for 95% of the users, except those that know how to interact with the Layer 1 OR contracts. In this case, it would be unfair to continue providing service on your dapp, as only 5 % of the users can use it. Note, this doesn't mean that the Layer 2 chain has stopped, as OR is not an actual chain. ++## Overview++L2 Sequencer Health Flag helps mitigate potential exploits when the Sequencer is unavailable by notifying the corresponding OR protocol to raise a flag on Layer 2.++The L2 Sequencer Health Flag consists of three actors:++1) Chainlink Cluster (a group of validator nodes) - executes the OCR Job every heartbeat "T" (the minimum frequency the Chainlink feed is configured to be updated)++2) The actual OCR feed reporting the Sequencer status - could be used for external users on Layer 1 to check OR protocol (e.g. Arbitrum) status++3) Validator - gets triggered by the OCR feed and executes the raise or lower flag action if the current answer is different from the previous one++## Checking the Sequencer Status++If you have contracts that rely on Layer 2 Chainlink Price Feeds, you should add an extra check for each of your contracts. To implement, use the following sample:++```solidity+pragma solidity ^0.6.0;++import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";+import "@chainlink/contracts/src/v0.6/interfaces/FlagsInterface.sol";++contract OCRPriceConsumer {+		// Identifier of the Sequencer offline flag on the Flags contract +    address constant private FLAG_ARBITRUM_SEQ_OFFLINE = address(bytes20(bytes32(uint256(keccak256("chainlink.flags.arbitrum-seq-offline")) - 1)));+    AggregatorV3Interface internal priceFeed;+    FlagsInterface internal chainlinkFlags;+    +    /**+     * Network: Arbitrum Rinkeby+     * Aggregator: ETH/USD+     * Agg Address: 0x5f0423B1a6935dc5596e7A24d98532b67A0AeFd8+     * Flags Address: 0x491B1dDA0A8fa069bbC1125133A975BF4e85a91b

Let me add both into the Notion doc then

dmitrydao

comment created time in a month

PullRequestReviewEvent

Pull request review commentsmartcontractkit/documentation

add l2 sequence health flag

+---+layout: nodes.liquid+date: Last Modified+title: "L2 Sequencer Health Flag Docs"+permalink: "docs/l2-sequencer-flag/"+---++The idea behind an Optimistic Rollup (OR) type of protocol is to move all execution off-chain and keep all transaction data available on-chain. Such protocols have a special off-chain component, a Sequencer, that executes and rolls up the Layer 2 transactions by batching multiple transactions into a single one.++If a sequencer becomes unavailable, it becomes impossible to access read/write APIs that consumers are using so every dapp will be down for 95% of the users, except those that know how to interact with the Layer 1 OR contracts. In this case, it would be unfair to continue providing service on your dapp, as only 5 % of the users can use it. Note, this doesn't mean that the Layer 2 chain has stopped, as OR is not an actual chain. ++## Overview++L2 Sequencer Health Flag helps mitigate potential exploits when the Sequencer is unavailable by notifying the corresponding OR protocol to raise a flag on Layer 2.++The L2 Sequencer Health Flag consists of three actors:++1) Chainlink Cluster (a group of validator nodes) - executes the OCR Job every heartbeat "T" (the minimum frequency the Chainlink feed is configured to be updated)++2) The actual OCR feed reporting the Sequencer status - could be used for external users on Layer 1 to check OR protocol (e.g. Arbitrum) status++3) Validator - gets triggered by the OCR feed and executes the raise or lower flag action if the current answer is different from the previous one++## Checking the Sequencer Status++If you have contracts that rely on Layer 2 Chainlink Price Feeds, you should add an extra check for each of your contracts. To implement, use the following sample:++```solidity+pragma solidity ^0.6.0;++import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";+import "@chainlink/contracts/src/v0.6/interfaces/FlagsInterface.sol";++contract OCRPriceConsumer {+		// Identifier of the Sequencer offline flag on the Flags contract +    address constant private FLAG_ARBITRUM_SEQ_OFFLINE = address(bytes20(bytes32(uint256(keccak256("chainlink.flags.arbitrum-seq-offline")) - 1)));

We don't have that, but I don't feel it super necessary. This flags ids aren't supposed to change, and there will be only one per network

dmitrydao

comment created time in a month

PullRequestReviewEvent

Pull request review commentsmartcontractkit/documentation

add l2 sequence health flag

+---+layout: nodes.liquid+date: Last Modified+title: "L2 Sequencer Health Flag Docs"+permalink: "docs/l2-sequencer-flag/"+---++The idea behind an Optimistic Rollup (OR) type of protocol is to move all execution off-chain and keep all transaction data available on-chain. Such protocols have a special off-chain component, a Sequencer, that executes and rolls up the Layer 2 transactions by batching multiple transactions into a single one.++If a sequencer becomes unavailable, it becomes impossible to access read/write APIs that consumers are using so every dapp will be down for 95% of the users, except those that know how to interact with the Layer 1 OR contracts. In this case, it would be unfair to continue providing service on your dapp, as only 5 % of the users can use it. Note, this doesn't mean that the Layer 2 chain has stopped, as OR is not an actual chain. ++## Overview++L2 Sequencer Health Flag helps mitigate potential exploits when the Sequencer is unavailable by notifying the corresponding OR protocol to raise a flag on Layer 2.++The L2 Sequencer Health Flag consists of three actors:++1) Chainlink Cluster (a group of validator nodes) - executes the OCR Job every heartbeat "T" (the minimum frequency the Chainlink feed is configured to be updated)++2) The actual OCR feed reporting the Sequencer status - could be used for external users on Layer 1 to check OR protocol (e.g. Arbitrum) status++3) Validator - gets triggered by the OCR feed and executes the raise or lower flag action if the current answer is different from the previous one++## Checking the Sequencer Status++If you have contracts that rely on Layer 2 Chainlink Price Feeds, you should add an extra check for each of your contracts. To implement, use the following sample:++```solidity+pragma solidity ^0.6.0;++import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";+import "@chainlink/contracts/src/v0.6/interfaces/FlagsInterface.sol";++contract OCRPriceConsumer {+		// Identifier of the Sequencer offline flag on the Flags contract +    address constant private FLAG_ARBITRUM_SEQ_OFFLINE = address(bytes20(bytes32(uint256(keccak256("chainlink.flags.arbitrum-seq-offline")) - 1)));+    AggregatorV3Interface internal priceFeed;+    FlagsInterface internal chainlinkFlags;+    +    /**+     * Network: Arbitrum Rinkeby+     * Aggregator: ETH/USD+     * Agg Address: 0x5f0423B1a6935dc5596e7A24d98532b67A0AeFd8+     * Flags Address: 0x491B1dDA0A8fa069bbC1125133A975BF4e85a91b

The current code example mentions Arbitrum Rinkeby, if we list the mainnet contracts, should we change to Arbitrum mainnet?

dmitrydao

comment created time in a month

PullRequestReviewEvent

Pull request review commentsmartcontractkit/documentation

add l2 sequence health flag

+---+layout: nodes.liquid+date: Last Modified+title: "L2 Sequencer Health Flag Docs"+permalink: "docs/l2-sequencer-flag/"+---++The idea behind an Optimistic Rollup (OR) type of protocol is to move all execution off-chain and keep all transaction data available on-chain. Such protocols have a special off-chain component, a Sequencer, that executes and rolls up the Layer 2 transactions by batching multiple transactions into a single one.++If a sequencer becomes unavailable, it becomes impossible to access read/write APIs that consumers are using so every dapp will be down for 95% of the users, except those that know how to interact with the Layer 1 OR contracts. In this case, it would be unfair to continue providing service on your dapp, as only 5 % of the users can use it. Note, this doesn't mean that the Layer 2 chain has stopped, as OR is not an actual chain. ++## Overview++L2 Sequencer Health Flag helps mitigate potential exploits when the Sequencer is unavailable by notifying the corresponding OR protocol to raise a flag on Layer 2.++The L2 Sequencer Health Flag consists of three actors:++1) Chainlink Cluster (a group of validator nodes) - executes the OCR Job every heartbeat "T" (the minimum frequency the Chainlink feed is configured to be updated)++2) The actual OCR feed reporting the Sequencer status - could be used for external users on Layer 1 to check OR protocol (e.g. Arbitrum) status++3) Validator - gets triggered by the OCR feed and executes the raise or lower flag action if the current answer is different from the previous one++## Checking the Sequencer Status++If you have contracts that rely on Layer 2 Chainlink Price Feeds, you should add an extra check for each of your contracts. To implement, use the following sample:++```solidity+pragma solidity ^0.6.0;++import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";+import "@chainlink/contracts/src/v0.6/interfaces/FlagsInterface.sol";++contract OCRPriceConsumer {+		// Identifier of the Sequencer offline flag on the Flags contract +    address constant private FLAG_ARBITRUM_SEQ_OFFLINE = address(bytes20(bytes32(uint256(keccak256("chainlink.flags.arbitrum-seq-offline")) - 1)));

What do you mean exactly? Devs should get the use the flags contract using the identifier as at the example

dmitrydao

comment created time in a month