flare-foundation · AmadiaFlare · Dec 16, 2025 · Dec 16, 2025
@@ -0,0 +1,5 @@
+ {
+    "rules": {
+      "one-sentence-per-line": true
+    }
+  }
@@ -22,9 +22,8 @@ We welcome:
     - Examples (`examples/`)
     - automation and docgen scripts (`automations/`, `docgen/`)
 
-3.  **Follow Style Guides:**
-    - **Code/Docs:** Run [Pre-PR checks](#pre-pr-checks). Match existing code style.
-    - **Diagrams:** Adhere to the [Diagram Style Guide](#diagrams-style-guide) for consistency.
+3.  **Follow Style Guides:** - **Code/Docs:** Run [Pre-PR checks](#pre-pr-checks).
+    Match existing code style. - **Diagrams:** Adhere to the [Diagram Style Guide](#diagrams-style-guide) for consistency.
 
 4.  **Commit Your Changes:** We require [Conventional Commits](https://www.conventionalcommits.org/) format for clear history and automated changelogs.
 

@@ -14,7 +14,8 @@ Sourced from `IFdcHub.sol` on [GitHub](https://github.com/flare-foundation/flare
 
 ## Overview
 
-The IFdcHub interface serves as the main entry point for applications requesting attestations from the Flare Data Connector. It provides functionality to request attestations, access configuration contracts, and handle related events.
+The IFdcHub interface serves as the main entry point for applications requesting attestations from the Flare Data Connector.
+It provides functionality to request attestations, access configuration contracts, and handle related events.
 
 ## Functions
 

@@ -14,7 +14,8 @@ Sourced from `IFdcInflationConfigurations.sol` on [GitHub](https://github.com/fl
 
 ## Overview
 
-The IFdcInflationConfigurations interface allows access to the inflation distribution settings for different attestation types and sources within the Flare Data Connector system. These configurations determine how inflation rewards are allocated to validators based on the attestation requests they process.
+The IFdcInflationConfigurations interface allows access to the inflation distribution settings for different attestation types and sources within the Flare Data Connector system.
+These configurations determine how inflation rewards are allocated to validators based on the attestation requests they process.
 
 ## Functions
 

@@ -14,13 +14,15 @@ Sourced from `IFdcRequestFeeConfigurations.sol` on [GitHub](https://github.com/f
 
 ## Overview
 
-The IFdcRequestFeeConfigurations interface provides functionality for managing and retrieving fees associated with attestation requests in the Flare Data Connector (FDC) system. It allows for querying the base fee required for specific attestation requests.
+The IFdcRequestFeeConfigurations interface provides functionality for managing and retrieving fees associated with attestation requests in the Flare Data Connector (FDC) system.
+It allows for querying the base fee required for specific attestation requests.
 
 ## Functions
 
 ### getRequestFee
 
-Method to get the base fee for an attestation request. It reverts if the request is not supported.
+Method to get the base fee for an attestation request.
+It reverts if the request is not supported.
 
 ```solidity
 function getRequestFee(

@@ -14,7 +14,8 @@ Sourced from `IFdcVerification.sol` on [GitHub](https://github.com/flare-foundat
 
 ## Overview
 
-The IFdcVerification interface provides methods to verify different types of attestations from the Flare Data Connector. Smart contracts can use these verification functions to validate proofs provided by the State Connector system, ensuring the authenticity and integrity of the external data being used.
+The IFdcVerification interface provides methods to verify different types of attestations from the Flare Data Connector.
+Smart contracts can use these verification functions to validate proofs provided by the State Connector system, ensuring the authenticity and integrity of the external data being used.
 
 ## Verification Functions
 

@@ -12,7 +12,8 @@ import FTSOV2FeedsById from "!!raw-loader!/examples/developer-hub-solidity/FTSOV
 import FTSOV2FeedsByIdWei from "!!raw-loader!/examples/developer-hub-solidity/FTSOV2FeedsByIdWei.sol";
 import FTSOV2AnchorConsumer from "!!raw-loader!/examples/developer-hub-solidity/FTSOV2AnchorConsumer.sol";
 
-Primary interface for interacting with FTSOv2. This is a long-term support (LTS) interface, designed to ensure continuity even as underlying contracts evolve or protocols migrate to new versions.
+Primary interface for interacting with FTSOv2.
+This is a long-term support (LTS) interface, designed to ensure continuity even as underlying contracts evolve or protocols migrate to new versions.
 
 Sourced from `FtsoV2Interface.sol` on [GitHub](https://github.com/flare-foundation/flare-smart-contracts-v2/blob/main/contracts/userInterfaces/LTS/FtsoV2Interface.sol).
 

@@ -87,9 +87,11 @@ function getScale(
 
 ### offerIncentive
 
-The entry point for third parties to make incentive offers. It accepts a payment and, using the contents of
+The entry point for third parties to make incentive offers.
+It accepts a payment and, using the contents of
 `_offer`, computes how much the expected sample size will be increased to apply the requested (but capped) range
-increase. If the ultimate value of the range exceeds the cap, funds are returned to the sender in proportion to
+increase.
+If the ultimate value of the range exceeds the cap, funds are returned to the sender in proportion to
 the amount by which the increase is adjusted to reach the cap.
 
 ```solidity

@@ -28,7 +28,8 @@ function blockScoreCutoff(
 
 #### Returns
 
-- `_cutoff`: The upper endpoint of the acceptable range of "scores" that providers generate for sortition. A score below the cutoff indicates eligibility to submit updates in the present sortition round.
+- `_cutoff`: The upper endpoint of the acceptable range of "scores" that providers generate for sortition.
+  A score below the cutoff indicates eligibility to submit updates in the present sortition round.
 
 ### currentRewardEpochId
 
@@ -54,7 +55,8 @@ function currentScoreCutoff(
 
 #### Returns
 
-- `_cutoff`: The upper endpoint of the acceptable range of "scores" that providers generate for sortition. A score below the cutoff indicates eligibility to submit updates in the present sortition round.
+- `_cutoff`: The upper endpoint of the acceptable range of "scores" that providers generate for sortition.
+  A score below the cutoff indicates eligibility to submit updates in the present sortition round.
 
 ### currentSortitionWeight
 
@@ -70,11 +72,13 @@ function currentSortitionWeight(
 
 #### Parameters
 
-- `_signingPolicyAddress`: The signing policy address of the specified provider. This is different from the sender of an update transaction, due to the signature included in the `FastUpdates` type.
+- `_signingPolicyAddress`: The signing policy address of the specified provider.
+  This is different from the sender of an update transaction, due to the signature included in the `FastUpdates` type.
 
 #### Returns
 
-- `_weight`: The specified provider's weight for sortition purposes. This is derived from the provider's delegation weight for the FTSO, but rescaled against a fixed number of "virtual providers", indicating how many potential updates a single provider may make in a sortition round.
+- `_weight`: The specified provider's weight for sortition purposes.
+  This is derived from the provider's delegation weight for the FTSO, but rescaled against a fixed number of "virtual providers", indicating how many potential updates a single provider may make in a sortition round.
 
 ### fetchAllCurrentFeeds
 
@@ -140,7 +144,8 @@ function numberOfUpdates(
 
 #### Returns
 
-- `_noOfUpdates`: The number of updates submitted in each block for the last `_historySize` blocks. The array is ordered from the current block to the oldest block.
+- `_noOfUpdates`: The number of updates submitted in each block for the last `_historySize` blocks.
+  The array is ordered from the current block to the oldest block.
 
 ### numberOfUpdatesInBlock
 
@@ -165,7 +170,8 @@ function numberOfUpdatesInBlock(
 ### submissionWindow
 
 The submission window is a number of blocks forming a "grace period" after a round of sortition starts,
-during which providers may submit updates for that round. In other words, each block starts a new round of
+during which providers may submit updates for that round.
+In other words, each block starts a new round of
 sortition and that round lasts `submissionWindow` blocks.
 
 ```solidity

@@ -23,7 +23,8 @@ function getFeedConfigurations(
 
 ### getFeedId
 
-Returns the feed id at a given index. Removed (unused) feed index will return bytes21(0).
+Returns the feed id at a given index.
+Removed (unused) feed index will return bytes21(0).
 
 ```solidity
 function getFeedId(
@@ -43,7 +44,8 @@ function getFeedId(
 
 ### getFeedIds
 
-Returns all feed ids. For removed (unused) feed indices, the feed id will be bytes21(0).
+Returns all feed ids.
+For removed (unused) feed indices, the feed id will be bytes21(0).
 
 ```solidity
 function getFeedIds(

@@ -184,13 +184,16 @@ function protocolFeeInWei(
 
 Finalization function for new signing policies and protocol messages.
 It can be used as finalization contract on Flare chain or as relay contract on other EVM chain.
-Can be called in two modes. It expects calldata that is parsed in a custom manner.
+Can be called in two modes.
+It expects calldata that is parsed in a custom manner.
 Hence the transaction calls should assemble relevant calldata in the 'data' field.
 Depending on the data provided, the contract operations in essentially two modes:
-(1) Relaying signing policy. The structure of the calldata is:
+(1) Relaying signing policy.
+The structure of the calldata is:
 function signature (4 bytes) + active signing policy + 0 (1 byte) + new signing policy,
 total of exactly 4423 bytes.
-(2) Relaying signed message. The structure of the calldata is:
+(2) Relaying signed message.
+The structure of the calldata is:
 function signature (4 bytes) + signing policy + signed message (38 bytes) + ECDSA signatures with indices (67 bytes each)
 This case splits into two subcases: - protocolMessageId = 1: Message id must be of the form (protocolMessageId, 0, 0, merkleRoot).
 The validity of the signatures of sufficient weight is checked and if
@@ -252,7 +255,8 @@ function toSigningPolicyHash(
 
 Verifies the leaf (or intermediate node) with the Merkle proof against the Merkle root
 for given protocol id and voting round id.
-A fee may need to be paid. It is protocol specific.
+A fee may need to be paid.
+It is protocol specific.
 **NOTE:** Overpayment is not refunded.
 
 ```solidity

@@ -12,7 +12,8 @@ Sourced from `ISubmission.sol` on [GitHub](https://github.com/flare-foundation/f
 
 ### getCurrentRandom
 
-Returns current random number. Method reverts if random number was not generated securely.
+Returns current random number.
+Method reverts if random number was not generated securely.
 
 ```solidity
 function getCurrentRandom(
@@ -65,7 +66,8 @@ function getCurrentRandomWithQualityAndTimestamp(
 
 ### submit1
 
-Submit1 method. Used in multiple protocols (i.e. as FTSO commit method).
+Submit1 method.
+Used in multiple protocols (i.e. as FTSO commit method).
 
 ```solidity
 function submit1(
@@ -76,7 +78,8 @@ function submit1(
 
 ### submit2
 
-Submit2 method. Used in multiple protocols (i.e. as FTSO reveal method).
+Submit2 method.
+Used in multiple protocols (i.e. as FTSO reveal method).
 
 ```solidity
 function submit2(
@@ -87,7 +90,8 @@ function submit2(
 
 ### submit3
 
-Submit3 method. Future usage.
+Submit3 method.
+Future usage.
 
 ```solidity
 function submit3(
@@ -98,7 +102,8 @@ function submit3(
 
 ### submitAndPass
 
-SubmitAndPass method. Future usage.
+SubmitAndPass method.
+Future usage.
 
 ```solidity
 function submitAndPass(
@@ -114,7 +119,8 @@ function submitAndPass(
 
 ### submitSignatures
 
-SubmitSignatures method. Used in multiple protocols (i.e. as FTSO submit signature method).
+SubmitSignatures method.
+Used in multiple protocols (i.e. as FTSO submit signature method).
 
 ```solidity
 function submitSignatures(

@@ -24,7 +24,8 @@ function setAutoClaiming(
 
 #### Parameters
 
-- `_executors`: The new executors. All old executors will be deleted and replaced by these.
+- `_executors`: The new executors.
+  All old executors will be deleted and replaced by these.
 - `_enableDelegationAccount`:
 
 ### setClaimExecutors
@@ -40,7 +41,8 @@ function setClaimExecutors(
 
 #### Parameters
 
-- `_executors`: The new executors. All old executors will be deleted and replaced by these.
+- `_executors`: The new executors.
+  All old executors will be deleted and replaced by these.
 
 ### setAllowedClaimRecipients
 
@@ -55,7 +57,8 @@ function setAllowedClaimRecipients(
 
 #### Parameters
 
-- `_recipients`: The new allowed recipients. All old recipients will be deleted and replaced by these.
+- `_recipients`: The new allowed recipients.
+  All old recipients will be deleted and replaced by these.
 
 ### enableDelegationAccount
 
@@ -151,7 +154,8 @@ function delegate(
 #### Parameters
 
 - `_to`: The address of the recipient
-- `_bips`: The percentage of voting power to be delegated expressed in basis points (1/100 of one percent). Not cumulative - every call resets the delegation value (and value of 0 revokes delegation).
+- `_bips`: The percentage of voting power to be delegated expressed in basis points (1/100 of one percent).
+  Not cumulative - every call resets the delegation value (and value of 0 revokes delegation).
 
 ### batchDelegate
 
@@ -168,7 +172,8 @@ function batchDelegate(
 #### Parameters
 
 - `_delegatees`: The addresses of the new recipients.
-- `_bips`: The percentages of voting power to be delegated expressed in basis points (1/100 of one percent). Total of all `_bips` values must be at most 10000.
+- `_bips`: The percentages of voting power to be delegated expressed in basis points (1/100 of one percent).
+  Total of all `_bips` values must be at most 10000.
 
 ### undelegateAll
 
@@ -251,7 +256,8 @@ function transferExternalToken(
 
 ### accountToDelegationAccount
 
-Gets the delegation account of the `_owner`. Returns address(0) if not created yet.
+Gets the delegation account of the `_owner`.
+Returns address(0) if not created yet.
 
 ```solidity
 function accountToDelegationAccount(
@@ -262,7 +268,8 @@ function accountToDelegationAccount(
 
 ### getDelegationAccountData
 
-Gets the delegation account data for the `_owner`. Returns address(0) if not created yet.
+Gets the delegation account data for the `_owner`.
+Returns address(0) if not created yet.
 
 ```solidity
 function getDelegationAccountData(

@@ -8,7 +8,8 @@ Interface for managing FlareDrop claims.
 
 Sourced from `IDistributionToDelegators.sol` on [GitLab](https://gitlab.com/flarenetwork/flare-smart-contracts/-/blob/master/contracts/userInterfaces/IDistributionToDelegators.sol).
 
-Manages the ongoing distribution of tokens from the Delegation Incentive Pool (the "FlareDrop"). The approval of [FIP.01](https://proposals.flare.network/FIP/FIP_1) created this pool, that releases its tokens every 30 days, over a period of 36 months, to all accounts holding Wrapped FLR.
+Manages the ongoing distribution of tokens from the Delegation Incentive Pool (the "FlareDrop").
+The approval of [FIP.01](https://proposals.flare.network/FIP/FIP_1) created this pool, that releases its tokens every 30 days, over a period of 36 months, to all accounts holding Wrapped FLR.
 
 ## Functions
 
@@ -49,7 +50,8 @@ Allows batch claiming for the list of '\_rewardOwners' up to given '\_month'.
 If reward owner has enabled delegation account, rewards are also claimed for that delegation account and
 total claimed amount is sent to that delegation account, otherwise claimed amount is sent to owner's account.
 Claimed amount is automatically wrapped.
-Method can be used by reward owner or executor. If executor is registered with fee > 0,
+Method can be used by reward owner or executor.
+If executor is registered with fee > 0,
 then fee is paid to executor for each claimed address from the list.
 
 ```solidity