Sequence security record
As of 30 Oct 2026, Sequence has 3 audit reports by 1 security firm on Trustblock; the latest is by Quantstamp, dated 2 Dec 2025. Those reports list no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Audits3
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Sequence - Identity Document | Security firm: Quantstamp | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · certificate.quantstamp.com |
| Sequence | Security firm: Quantstamp | Date: | Scope: Files named in the report | No open critical findings | Open · certificate.quantstamp.com |
| Sequence Smart Wallet | Security firm: Quantstamp | Date: | Scope: Files named in the report | No open critical findings | Open · certificate.quantstamp.com |
Findings71
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 9 |
| Medium | 1 | 0 | 16 |
| Low | 21 | 9 | 15 |
HighAvoid Legacy EC2 Metadata FormatSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The EC2 instances are configured to use Instance Metadata Service version 1 (IMDSv1), which is susceptible to server-side request forgery (SSRF) and other local privilege escalation attacks. IMDSv1 is a request/response interface accessible via HTTP and lacks the session-based protections introduced in IMDSv2. Because it allows for unauthenticated HTTP requests from any process running on the instance, an attacker with the ability to execute code or exploit SSRF vulnerabilities can retrieve sensitive metadata — including IAM role credentials — from the metadata service.
Open the reportHighEnable Deletion Protection for Load BalancersSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
Load balancers should be protected from accidental deletion.
Open the reportHighEnable Image Scanning for Docker Images Stored in EcrSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The ECR container registry should do a vulnerability scan on every pushed image.
Open the reportHighHigh Severity CVE Present in Code BaseSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The system includes a dependency that is affected by CVE-2025-22869, a high-severity vulnerability. This CVE refers to a known flaw in the `golang.org/x/crypto`. Use of vulnerable third-party components introduces serious risks, as they may be exploited even without a direct flaw in the application's own code. Attackers often scan systems for known vulnerable versions, especially those that are widely used. Failure to patch or update this dependency may violate basic supply chain security principles and potentially leave the system open to compromise.
Open the reportHighIssuers in JWT tokens should never allow for unencrypted trafficSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The OpenID Connect issuer (iss) used in the authentication flow is configured with an insecure `http://` scheme, violating the OIDC specification and creating a critical security risk. According to the OpenID Connect Core 1.0 specification, the issuer MUST use the https scheme to ensure integrity, authenticity, and confidentiality of identity tokens and discovery documents. Using plain http opens the door to MITM (man-in-the-middle) attacks, token forgery, and discovery document tampering, especially if DNS spoofing or network interception is possible. Even if the server is internal or behind a VPN, relying on http for OIDC interactions undermines the security model of federated identity, which assumes cryptographically verifiable trust boundaries.
Open the reportHighJWT Token Validation and Verification Are Explicitly DisabledSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
`identity-instrument-master/auth/idtoken/auth_handler.go`, line 108: The application disables both signature verification and claims validation when parsing a JWT token: ``` jwt.Parse([]byte(idToken), jwt.WithVerify(false), jwt.WithValidate(false)) ``` This effectively turns off all critical security checks provided by JWTs, allowing any token—malicious or malformed—to be accepted as valid. An attacker can forge tokens with arbitrary claims, including user identifiers, roles, and permissions, potentially resulting in full account takeover, privilege escalation, or bypass of authentication. JWT's purpose is to assert identity and claims integrity via cryptographic signatures. Disabling .WithVerify(false) skips this integrity check, while .WithValidate(false) disables checks like expiration (exp) or issuer (iss). Combined, this configuration nullifies the entire trust model of JWTs.
Open the reportHighMissing Key Generation Update LogicSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The Decrypt function in `encryption/pool.go` contains a TODO comment indicating that key generation should be updated if needed, but this logic is not implemented. When a key from an older generation is used for decryption, the system should automatically update it to the current generation to ensure it remains accessible as TTPs rotate their keys. The system does not check if the key's generation is current, nor does it attempt to update the key to the latest generation. If keys cannot be updated to the current generation, users may lose access to their encrypted data.
Open the reportHighRecommending to Sanitize Input and Use Multi-Tier Architecture Instead of Passing Down the HTTP Context to Every FunctionSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The HTTP context of API calls contains all external, user-provided information. By nature, this data cannot be trusted and needs to be validated against tampering. The most common design for APIs consists of a resource layer, which checks the inputs for validity and passes down the sanitized inputs for further processing. The context itself should not be passed further down.
Open the reportHighSet Immutable Tags for Docker Images Stored in EcrSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
In order to maintain stability with respect to image tags and versions, it is important to set the tags in ECR to be immutable.
Open the reportMediumA User Is Able to Pass in an Empty Nonce ValueSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The application contains logic that checks if the value of a variable nonceVal is equal to an empty string (`identity-instrument-master/rpc/internal/attestation/middleware.go`, line 69\) before performing further operations. However, if the input (Header `"X-Attestation-Nonce"`) is a string containing only whitespace (e.g., " "), the check incorrectly allows the code to continue, as it only excludes exactly empty strings. This leads to a scenario where malformed or unintended input values—such as whitespace—are treated as valid. In security-sensitive contexts, such as nonce verification, this can result in logic flaws, inconsistent behavior, or bypass conditions.
Open the reportShow 10 more
MediumAuth Commitment Overwrite Allows DoS on User AuthenticationSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
When initiating an auth flow, the identity instrument does not request any proof that one owns the auth keypair. The authkey parameter in any request simply represents the public key component of the keypair, and can be easily hijacked. An attacker could create a new auth flow with the a keypair that is already in use at the moment. This will allow the attacker to override the owner's auth key record, associating it with the attacker's signer. The system, however, will not allow the attacker, nor the true owner, to proceed with signing transactions, causing a temporary DoS. The owner, in turn, will be forced to re-authenticate.
Open the reportMediumAuth Session Could be Abused and Lead to DoS AttacksSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
Upon a valid auth flow, one could abuse the sign logic by submitting many sign requests. Whenever a user session is in place, code-level rate limiting is highly advisable as an extra security layer to prevent Denial-of-Service (DoS) attacks, since cloud-based ones are less granular and generally based on IPs, which could be rotated.
Open the reportMediumAuto-Redirect to Auth Does Not Work for Invalid SubdomainsSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The application renders parts of the authenticated user interface (UI) to unauthenticated users who visit arbitrary or deep-linked paths (e.g., [https://v3.sequence-dev.app/foo](https://v3.sequence-dev.app/foo)). While backend API calls fail due to lack of authentication, the presence of elements like "Logout" and partial dashboard components implies that routing and view rendering are not properly gated by authentication status. This exposes internal UI logic and workflows, which can aid attackers in reconnaissance, phishing, or crafting targeted social engineering attacks. In more severe scenarios, it may also leak static content or mislead users into believing they are logged in. Even if no sensitive data is exposed directly, showing logged-in-only UI to unauthenticated users violates the principle of least privilege and secure defaults.
Open the reportMediumDrop Invalid Headers on the Load Balancer LevelSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
A variety of attacks are actually performed using invalid symbols in headers. There is a setting in the load balancer, if it is an application load balancer, to prevent those headers to be forwarded to the target resource.
Open the reportMediumDynamoDB Table Safety Considerations with Respect to Current DesignSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
There are two critical considerations in the way the application interacts with Amazon DynamoDB, especially in the context of permanent data storage and unbounded payload sizes: A. Time-to-Live (TTL) Not Explicitly Controlled DynamoDB offers an optional Time to Live (TTL) mechanism that allows automatic deletion of expired items, based on a user-defined timestamp attribute. If the application intends to store items permanently, it is vital that: - No TTL attribute (e.g., ttl or expirationTime) is accidentally set. - Data written into the table is validated to ensure TTL values are not unintentionally populated. If TTL is enabled without strict control, this can lead to silent data deletion, resulting in: - Unexpected missing records - Failures in business logic - Irrecoverable loss of important data (DynamoDB TTL deletions are permanent) B. Risk of Exceeding the 400 KB Item Limit DynamoDB enforces a hard 400 KB size limit per item (including attribute names and metadata). If the data model allows unbounded growth — such as appending to a list or storing user-generated content — there's a real risk of: - Write failures (ValidationException: Item size has exceeded the maximum allowed size) - Application crashes or inconsistencies due to write failures - Inability to restore or replicate oversized items This is especially critical when handling logs, document snapshots, or unvalidated client input.
Open the reportMediumEnable Enhanced Monitoring on EC2 InstancesSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
When using EC2-instances, if real-time view on data is critical, it is advisable to enable enhanced monitoring. This also enables teams to get alarms more timely.
Open the reportMediumEnsure to Have Termination Protection for EC2 InstancesSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
When using EC2-instances, it is advisable to enable termination protection, since it is otherwise possible to accidentally lose data or put the cluster in an undesired state.
Open the reportMediumLack of Email and Length Validation Poses Security RisksSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
In the OTP authentication flow, in the commit stage, input email lengths are not validated. This creates an opportunity for malicious actors to send OTP requests with a large payload. This could open-up DoS attack vectors, such as Denial-of-Service (e.g., memory exaustion) or simply cause AWS costs to increase. Developers seem to be somewhat aware of this issue, as validation is currently stated as a TODO comment. ``` func (s \*Sender) NormalizeRecipient(recipient string) (string, error) { // TODO: Validate email address return Normalize(recipient), nil } ``` Similar to the missing email validation logic in the OTP-based auth flow, the sign logic does not verify the digest length, allowing for any digest size (generally expected to be 256 bytes long). The same issues concerning a potentially unbounded input apply here, namely, the risk of DoS attacks and potentially higher AWS costs. Similar to the ones described above, the `auth_key` length should be validated as well.
Open the reportMediumNo CI/CD Tool in Place for Pipeline TestsSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
In order to prevent issues when deploying changes to the code, it is recommended to employ a so-called CI/CD tool. Examples are: - Github Workflows - Jenkins - Bitbucket pipelines - Gitlab pipelines - CircleCI These tools can be used to ensure that a proper code change process is in place and that tests are run every time a change takes place.
Open the reportMediumNo locked in version in DockerfileSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
When using `FROM` directives in Docker files, it is important to specify the version directly and not just use latest (since this is a changing tag). Alternatively, define a specific digest of the image you aim to use.
Open the reportShow 10 more
MediumNo Way to Rotate Underlying Private KeysSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The system does not provide a mechanism to rotate or replace the underlying private keys used for cryptographic operations. Key rotation is a critical security practice to limit the impact of key compromise and to comply with security best practices.
Open the reportMediumUnhandled Errors in CodeSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
Several places in the application lack proper error handling, where errors are either ignored silently, logged without context, or not acted upon. This practice leads to undefined behavior, unstable execution paths, and security blind spots, especially if these failures impact authentication, access control, data validation, or external service communication. Uncaught errors can: - Suppress indicators of failed security checks - Lead to silent partial failures or inconsistent states - Open up denial-of-service conditions or privilege escalation pathways when failure isn’t managed Below is a list of instances where error handling was found to be missing or inadequate: - `/identity-instrument-master/auth/authcode/auth_handler.go`, line 270: The function `jwtKey.Set` can also produce an error, which is not explicitly checked for in this function. - `/identity-instrument-master/cmd/ingress-proxy/main.go`, line 30 - `/identity-instrument-master/data/cipher_key.go`, line 53: The `Write` function is not explicitly checked for an error that may be produced. - `/identity-instrument-master/encryption/pool.go`, line 219\. - `/identity-instrument-master/proto/identity-instrument.gen.go`, lines 554, 541, 540 and 528\. - `/identity-instrument-master/rpc/internal/attestation/middleware.go`, line 64\. - `/identity-instrument-master/rpc/internal/attestation/userdata.go`, line 17\. - `/identity-instrument-master/rpc/auth.go`, line 369\.
Open the reportMediumUse Encryption at Rest with Dynamodb TablesSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
When defining a DynamoDB table, one needs to ensure that the data on the server is encrypted.
Open the reportMediumPotential Signature Replayability Across ChainsSequence · Quantstamp · 12 Jan 2024Fixed
The lack of chain ID integration in contract's message hashing could pose risks in scenarios involving multiple blockchain networks. 1. The `ERC1155BaseToken` contract inherits `ERC1155Meta` (out of scope) which includes functions `metaSafeTransferFrom()` and `metaSafeBatchTransferFrom()`. The functions enable assets to be transferred from the owner to a recipient, provided there is a valid signature from the asset owner authorizing the transfer. The transfer functions use the `hashEIP712Message()` for message hashing. However, this function does not include a chain ID in its implementation. The absence of a chain ID in the EIP-712 message structure could lead to a situation where a valid signature on one blockchain might be replayed on another blockchain. 2. Although the `Trust` contract checks the validity of the signed message in `isValidSignature()`, the hashed value excludes a chain ID, and, therefore, the signed message may be reused across different Ethereum chains. Typically, the inclusion of a chain ID in the signed message is a common security measure to prevent such replay attacks, ensuring that signatures are valid only on the intended blockchain.
Open the reportMediumToken Sale Owners Can Front-Run Mints With Increased CostSequence · Quantstamp · 12 Jan 2024Fixed
The `mint()` function in the contracts `ERC721Sale` and `ERC1155Sale`, is vulnerable to front running from the `MINT_ADMIN_ROLE`. If the `MINT_ADMIN_ROLE` finds a mint transaction in the mempool, and the mint caller has given sufficient approval, the `MINT_ADMIN_ROLE` can front-run the mint with a call to `setSaleDetails()` and increase the `cost`. Thus, the mint caller will pay more for the token than expected.
Open the reportLowSigned Messages Are Prone to Replay AttacksSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
From the code alone, it is unclear what format messages should have. If any, they are not enforced by the `Sign` logic. This leads to an absence of checks for replay attacks, including a nonce and chainid.
Open the reportLowUse Builder Libraries for Special StringsSequence - Identity Document · Quantstamp · 2 Dec 2025Fixed
The codebase builds URLs using manual string concatenation, such as: `/identity-instrument-master/cmd/ingress-proxy/main.go`, line 89: ``` url := "http://" + r.Host + r.URL.String() ``` This approach is error-prone and unsafe, especially when user input or variable data is embedded into URLs. Improper handling of special characters, path delimiters, or query parameters can lead to: - Incorrect URL encoding, breaking API calls or routing logic - Injection vulnerabilities, especially if user-controlled values are appended unchecked - Ambiguous or malformed URLs, which can degrade reliability or security This pattern bypasses standard encoding protections and lacks guardrails against constructing invalid or unsafe URLs — particularly problematic in systems that construct dynamic API calls, redirects, or query links.
Open the reportLow'Dead' CodeSequence · Quantstamp · 12 Jan 2024Fixed
"Dead" code refers to code which is never executed and hence makes no impact on the final result of running a program. Dead code raises a concern, since either the code is unnecessary or the necessary code's results were ignored. 1. `ERC1155Sale._ERC20_TRANSFERFROM_SELECTOR` is never used in `ERC1155Sale`. 2. `ERC721Sale._ERC20_TRANSFERFROM_SELECTOR` is never used in `ERC721Sale`.
Open the reportLowCollisions In `abi.encodePacked()`Sequence · Quantstamp · 12 Jan 2024Fixed
Factory contracts call `abi.encodePacked()` to concatenate the parameters of the contract before hashing the result. This is the salt used by `CREATE2` to generate the new contract. However, `abi.encodePacked()` does not pad the dynamic types, potentially leading to hash collisions (e.g. `[token, $token]`, will have the same hash as `[token$t, oken]`).
Open the reportLowCreate ERC-20 Offers in an Orderbook Designed for ERC-1155 and ERC-721Sequence · Quantstamp · 12 Jan 2024Fixed
The orderbook, designed for handling ERC-1155 and ERC-721 tokens, is vulnerable to unintended listings of ERC-20 tokens due to the identical `transferFrom()` function signature shared between ERC-20 and ERC-721 standards. In both standards, the function signature is `transferFrom(address, address, uint256)`. However, in the context of ERC-20, the third parameter (`uint256`) represents the amount of tokens to be transferred, while in ERC-721, it denotes the unique `tokenId` of the NFT. This similarity in function structure allows for the possibility of ERC-20 tokens being listed in the orderbook as if they were ERC-721 tokens, with the `tokenId` inadvertently interpreted as the quantity of ERC-20 tokens. This misalignment can lead to transactional errors and confusion, as the orderbook is not designed to accommodate the fungible nature and transactional semantics of ERC-20 tokens. Although unlikely, if a user were to unintentionally accept what they believe is an ERC-721 order, and they have a pre-existing ERC-20 token allowance set for the orderbook, this could lead to an unintentional transfer of ERC-20 tokens to the creator of the spoofed ERC-721 order. Although there is an approval check in `_hasApprovedTokens` when creating the spoofed ERC-721 order, the ownership validation occurs only when the order is a listing.
Open the reportShow 10 more
LowDeprecated FunctionsSequence · Quantstamp · 12 Jan 2024Fixed
Several initializers in the codebase call `_setupRole()` to assign privileged roles to certain addresses, instead of using `_grantRole()`. Both functions have the same effect, as `_setupRole()` just calls `_grantRole()`. `_setupRole()` will be deprecated in `v5.0.0` of OpenZeppelin contracts, and its use is not recommended in the current version used by the codebase (`v4.9.3`). See `_setupRole()` comment: ``` NOTE: This function is deprecated in favor of {_grantRole}. ```
Open the reportLowGas Optimization: Cache VariablesSequence · Quantstamp · 12 Jan 2024Fixed
Repeatedly accessing certain variables can be gas-intensive. To optimize gas usage, values frequently accessed should be stored in memory variables. Consider storing the value in a memory variable and reference the memory variable for the following variables: 1. `requests.length` from `Orderbook.createOrderBatch()` 2. `ordersIds.length` from `Orderbook.acceptOrderBatch()` 3. `ordersIds.length` from `Orderbook.getOrderBatch()` 4. `ordersIds.length` from `Orderbook.isOrderValidBatch()`
Open the reportLowGas Optimization: Use `calldata` Instead of `memory`Sequence · Quantstamp · 12 Jan 2024Fixed
Solidity's `calldata` is a read-only byte-addressable space where function arguments reside. It is more cost-effective to employ `calldata` over `memory`. This is because `calldata` is not stored in memory but is directly accessed from the function call data, resulting in gas savings. It is recommended to change the `memory` to `calldata` in the mentioned functions: 1. `createOrder()` 2. `createOrderBatch()` 3. `_createOrder()` 4. `acceptOrder()` 5. `_acceptOrder()` 6. `acceptOrderBatch()` 7. `getOrderBatch()` 8. `cancelOrderBatch()` 9. `isOrderValidBatch()`
Open the reportLowGreedy ContractsSequence · Quantstamp · 12 Jan 2024Fixed
Sale contracts can be configured to accept payments in ERC-20 or native tokens. However, the functions are `payable`, so a user can send native tokens by mistake, locking them in the contract.
Open the reportLowInconsistency in Order ID Retrieval for Partially Fulfilled NFT OrdersSequence · Quantstamp · 12 Jan 2024Fixed
The `hashOrder()` function generates an order ID by hashing order data, including `uint256 quantity`. However, for orders that are partially fulfilled, the `quantity` within an order changes over time with each partial fulfillment. As a result, the `hashOrder()` function cannot consistently calculate the correct `orderId` based on the current `_orders` state variable since varying quantities lead to different hash outputs and, consequently, different IDs. In the protocol, operations such as accepting or cancelling orders use only the `orderId` to reference the order. This issue is specifically relevant for off-chain components or other protocols that use `hashOrder()` to reference or retrieve the order ID based on order data. These systems may end up with mismatched or incorrect order IDs due to the changing quantities in orders over time.
Open the reportLowInsufficient Allowance Check in NFT Order CreationsSequence · Quantstamp · 12 Jan 2024Fixed
The NFT purchase process checks the buyer's token allowance based only on the token price and quantity, neglecting the additional royalty fees. This approach could result in situations where a buyer's approved allowance satisfies the token cost but falls short when royalty fees are included, leading to unsuccessful order fulfillment. `isOrderValid()` (for an order of "offer" type) verifies that the order creator gave enough allowance to cover the pay of the offer and also the royalties linked to the token. However, when a user creates an offer, `_createOrder()` verifies that enough allowance was provided to cover the new order, without taking royalties into account.
Open the reportLowOutdated CommentsSequence · Quantstamp · 12 Jan 2024Fixed
In several factory contracts, the following comment can be found: ``` @dev As `proxyOwner` owns the proxy, it will be unable to call the [...] functions. ``` However, the Sequence factories implement a modified Transparent Proxy pattern, where the administrator can also call the implementation, apart from the administration functions.
Open the reportLowPotential EVM Compatibility Issue in Solidity Version `>=0.8.20`Sequence · Quantstamp · 12 Jan 2024Fixed
According to the `foundry.toml` config file, the `Orderbook` contract is compiled in Solidity version `0.8.20` with an unspecified evm version. As a result, the contract bytecode may be compiled with the default evm version Shanghai and may include `PUSH0` opcodes, which are not supported on certain EVM chains, including BSC, [Arbitrum](https://docs.arbitrum.io/solidity-support), and [Optimism](https://community.optimism.io/docs/developers/build/differences/). The deployment or execution of the contract may fail due to the use of an invalid opcode.
Open the reportLowPrivileged Users Limited to One ERC-1155 Token Mint When Only the Global Sale is EnabledSequence · Quantstamp · 12 Jan 2024Fixed
The function `ERC1155Sale._payForActiveMint()`, called via `mint()`, collects the mint fees and checks if the caller is a valid leaf in the Merkle tree. If the caller is a valid leaf, the Merkle root is marked as used for the caller. However, since `_payForActiveMint()` allows for batch minting, and since the Merkle proof is verified for each minted token, minting will fail after one token per caller when only the global sale is enabled. This is not an issue when individual token sales are enabled and Merkle roots are unique for each token.
Open the reportLowRisk of NFT Loss when Accepting OrderSequence · Quantstamp · 12 Jan 2024Fixed
When accepting orders, the transferring ERC-721 tokens uses the `transferFrom()` function, which does not include safety checks to verify if the recipient is capable of handling ERC-721 tokens. This could lead to irreversible loss of NFTs if they are sent to contracts that do not implement the ERC-721 receiver interface.
Open the reportContracts
No deployed address is recorded for these audits.
The reports name a repository or files. Open a report to see its scope.
Show this on your site
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Content
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
Style
Format
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="sequence"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us