Iskra security record
As of 3 Nov 2026, Iskra has 4 audit reports by 1 security firm on Trustblock; the latest is by CertiK, dated 22 Apr 2024. Those reports list no open critical findings.
Record last updated . It holds audits, findings and contracts up to Nov 2026, and incidents up to Oct 2026. Trustblock does not review code.
Audits4
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Iskra - Audit 5 | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Iskra - ItemNFTSnapshot | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Iskra - Launchpad | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Iskra - Audit for Token (Part 1) | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
Findings45
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 8 | 2 | 0 |
| Medium | 0 | 0 | 2 |
| Low | 8 | 0 | 25 |
HighCentralization Risks in IGOVesting.solIskra - Launchpad · CertiK · 12 Jun 2023Open
In the contract `IGOVesting` the role `_operator` has authority over the functions shown in the diagram below. Any compromise to an `_operator` account may allow the hacker to take advantage of this authority and register or add new vesting for an account.  ----- In the contract `IGOVesting` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and: - transfer ownership to an address they control; - add or remove any address as an operator. 
Open the reportHighCentralization Risks in InitialGameOffering.solIskra - Launchpad · CertiK · 12 Jun 2023Open
In the contract `InitialGameOffering` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and : - transfer ownership to an address they control; - modify the time intervals of each status, if the contract state is `READY`; - modify the sale amounts, if the contract state is `READY`; - revoke the contract if the sale has not started yet, this allows the `owner` address to drain tokens from the contract; - set any address they control as the operator.  ------ In the contract `InitialGameOffering` the role `operator` has authority over the functions shown in the diagram below. Any compromise to the `operator` account may allow the hacker to take advantage of this authority and: - set any address they control as the new operator. - reclaim tokens when the contract state is `SALE_FINISHED`. 
Open the reportHighCentralization Risks in Launchpad.solIskra - Launchpad · CertiK · 12 Jun 2023Open
In the contract `Launchpad` the role `_operator` has authority over the functions shown in the diagram below. Any compromise to the `_operator` account may allow the hacker to take advantage of this authority and, set any address they control as the operator, interfere with the `IGO` contract by modifying important state variables. This contract has a lot of control over `InitialGameOffering` contracts. The hacker could also: - set an address they control as the fee recipient and set the fees to the maximum in order to divert tokens; - deploy malicious `InitialGameOffering` and `IGOVesting` contracts and make them appear legitimate since they will be deployed from the launchpad.  ---- In the contract `Launchpad` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and : - transfer ownership to an address they control; - change the `qualificationChecker` to an address of a malicious contract, this would allow to interfere with the signature mechanism; - change the oracle address, which is critical for the safety and reliability of `InitialGameOffering` contracts. 
Open the reportHighCentralization Risks in StructuredSignVerifier.soIskra - Launchpad · CertiK · 12 Jun 2023Open
In the contract `StructuredSignVerifier` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and : - transfer ownership to an address they control; - modify the `signLifespan`, which is used as a security parameter when verifying a signature. - set any address as the new `signer` which is a crucial parameter to ensure the signature mechanism works fine. 
Open the reportHighCentralized Control of Contract UpgradeIskra - Launchpad · CertiK · 12 Jun 2023Open
`IGOVesting`, `InitialGameOffering`, and `LaunchpadBase` are upgradeable contracts, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.
Open the reportHighCentralization Related RisksIskra - Audit for Token (Part 1) · CertiK · 17 May 2023Open
In the contract `MultiToken` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and: - transfer the ownership to an address they control; - change the URI; - pause or unpause the contract (if `MultiToken` is deployed as pausable); - grant or revoke the capacity to mint tokens from any address; - grant or revoke the capacity to burn tokens from any address (if `MultiToken` is deployed as pausable);  ----- ----- In the contract `UtilityToken` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and: - transfer ownership to an address they control; - grant or revoke the minter role from any address.  ---- In the contract `UtilityToken` the role `minters` has authority over the functions shown in the diagram below. Any compromise to the `minters` account may allow the hacker to take advantage of this authority and : - mint any amount of tokens to any address; - burn tokens they own or are approved to handle.  ----- ----- In the contract `ItemNFT` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and : - grant or revoke the capacity to mint tokens to any address; - grant or revoke the capacity to burn tokens to any address (if the contract has been deployed as burnable); - change the URI;  ----- ----- In the contract `Vesting` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and: - transfer the ownership to an address they control; - prepare a new vesting; - set the start of a vesting; - revoke the vesting and send the tokens to an address they control.  ---- In the contract `Vesting` the role `beneficiary` has authority over the functions shown in the diagram below. Any compromise to the `beneficiary` account may allow the hacker to take advantage of this authority and: - change the beneficiary address to an address they control; - claim tokens vested; 
Open the reportHighCentralized Control of Contract UpgradeIskra - Audit for Token (Part 1) · CertiK · 17 May 2023Open
`Vesting` is an upgradeable contract, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.
Open the reportHighInitial Token DistributionIskra - Audit for Token (Part 1) · CertiK · 17 May 2023Open
All tokens are sent to the contract deployer when deploying the contract. This is a potential centralization risk as the deployer can distribute tokens without the consensus of the community.
Open the reportLowBatchminting does not prevent overflowIskra - ItemNFTSnapshot · CertiK · 14 Aug 2023Open
The function `ERC721._mint()` updates the receiver balance as follows: ```solidity unchecked { // Will not overflow unless all 2**256 token ids are minted to the same owner. // Given that tokens are minted one by one, it is impossible in practice that // this ever happens. Might change if we allow batch minting. // The ERC fails to describe this case. _balances[to] += 1; } ``` In theory, the function `safeMintBatch()` could cause an overflow.
Open the reportLowRedundant Code ComponentsIskra - ItemNFTSnapshot · CertiK · 14 Aug 2023Open
In the ERC721Snapshot contract, a counter variable `_currentSnapshotId` is defined but never utilized. Although the internal function `_snapshot()` incrementing this counter is present, it is not invoked within the scope of the audited code. Additionally, the function `_getCurrentSnapshotId()`, which retrieves the counter's value, is overridden in the `ItemNFTSnapshot` contract, thus ensuring that `_currentSnapshotId` remains unused throughout
Open the reportShow 6 more
LowMissing Emit EventsIskra - Launchpad · CertiK · 12 Jun 2023Open
Events should be emitted in sensitive functions controlled by centralization roles.
Open the reportLowThird Party DependencyIskra - Launchpad · CertiK · 12 Jun 2023Open
The contract is serving as the underlying entity to interact with one or more third-party protocols. The scope of the audit treats third-party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. --- ```solidity=19 IExpTokenRule private _expTokenRule; ``` - The contract `IGOVesting` interacts with a third-party contract with `IExpTokenRule` interface via `_expTokenRule`. --- ```solidity=61 address[] private _paymentTokens; ``` - The contract `InitialGameOffering` interacts with a third-party contract with `IERC20Upgradeable` interface via `_paymentTokens`. --- ```solidity=242 address paymentToken, ``` - The function `InitialGameOffering._participate` interacts with a third-party contract with `IERC20Upgradeable` interface via `paymentToken`. ---- ```solidity=364 require(_launchpadRule.isOracle(msg.sender), "invalid msg.sender."); ``` The function `InitialGameOffering.submitLotteryResult` interacts with an address `oracle` declared in `LaunchpadBase`, through the interface `_launchpadRule` and the function `Launchpad.isOracle()`. \ The safety of `InitialGameOffering` lottery depends heavily on the reliability of this `oracle` address. ----- The contract `Launchpad.sol` is using functions from `BeaconProxyFactory.sol` which is outside the scope of this audit. The scope of the audit treats this contract as a black box and assumes its functional correctness.
Open the reportLowBatchminting does not prevent overflowIskra - Audit for Token (Part 1) · CertiK · 17 May 2023Open
The function `ERC721._mint()` updates the receiver balance as follows: ```solidity unchecked { // Will not overflow unless all 2**256 token ids are minted to the same owner. // Given that tokens are minted one by one, it is impossible in practice that // this ever happens. Might change if we allow batch minting. // The ERC fails to describe this case. _balances[to] += 1; } ``` In theory, the function `safeMintBatch()` could cause an overflow.
Open the reportLowCheck Effect Interaction Pattern ViolatedIskra - Audit for Token (Part 1) · CertiK · 17 May 2023Open
A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. *This finding is considered minor because the reentrancy only causes out-of-order events.*
Open the reportLowInaccurate Transfer AmountIskra - Audit for Token (Part 1) · CertiK · 17 May 2023Open
In `Vesting.sol`, the functions `prepare()` and `claim()` transfer specific amounts of tokens. However, in the linked locations the amount is multiplied by 1e18 in the transfer functions. The functions `transfer()` and `transferFrom()` from an ERC20 are already supposed to work without multiplying the amount by the decimals.
Open the reportLowThird Party DependencyIskra - Audit for Token (Part 1) · CertiK · 17 May 2023Open
The contract is serving as the underlying entity to interact with one third-party protocol. The scope of the audit treats third-party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. --- ```solidity=34 IERC20 public token; ``` - The contract `Vesting` interacts with a third-party contract with `IERC20` interface via `token`.
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="iskra"></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