Opulous security record
As of 3 Nov 2026, Opulous has 1 audit report on Trustblock, by CertiK, dated 4 Nov 2022. That report lists 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.
Audits1
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Opulous (Staking Pools) Addendum | Security firm: CertiK | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · skynet.certik.com |
Findings5
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 2 | 0 |
| Medium | 0 | 0 | 1 |
| Low | 0 | 0 | 2 |
MediumMissing Txn Basic ChecksOpulous (Staking Pools) Addendum · CertiK · 4 Nov 2022Fixed
The smart contract is missing some significant checks on transactions.
Open the reportLowExtracting `stake:amount`Opulous (Staking Pools) Addendum · CertiK · 4 Nov 2022Fixed
`stake:amount` is stored in the local mapping with `stake:slot` to be the key, and it is read and copied to the slot 2 of the scratchspace each time when the subroutine `set_stake_props` is triggered. For the other three fields in the mapping, `slot:time`, `slot:lockup` and `slot:apy`, they are not likely to reach the max value if the inputs are valid. The opcode `extract_uint64` will throw an error and revert the transaction if the number to be casted is greater than the max value of `uint64`.
Open the reportLowWhistlist Tokens Can Be Transferred By The FirstOpulous (Staking Pools) Addendum · CertiK · 4 Nov 2022Fixed
According to the [Opulous staking pool - Two Tokens Documentation](https://docs.google.com/presentation/d/10wPB30GeKNVZpofiLm_3iHmNNkwJq7o9mInTk56sjbo/edit#slide=id.g13845b68ce3_0_6), whitelist tokens will be used in the pool to control user access, and users who have a balance of the token will be able to stake in the pool. Our current understanding is that if the target ASA is owned by an admin address, then the admin can determine the initial set of addresses by transferring the target ASA to them. For example, let's say each address receives 10 tokenAlpha from the admin. Then the addresses with tokenAlpha can transfer their tokenAlpha balance to more addresses. Then all these addresses with tokenAlpha balance have permission to stake to the pool. We would like to confirm if the above-described behavior is intended and allowed. At meanwhile, it seems the `add_whitelist` branch can be renamed to `set_whitelist`, since it does not check if the `whitelist_token_id` is empty before `app_global_put`. We would like to confirm the intention of this branch as well.
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="opulous"></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