CertiK reviewed Pablo DeFi on 2 Jan 2024: 10 findings, 0 critical; 4 marked fixed, 6 open.
The original report was removed from its address (seen 18 Oct 2026).
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 4 | 0 | 0 |
| Medium | 0 | 0 | 1 |
| Low | 2 | 0 | 3 |
In the contract `ERC20` 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, changing fee, pair and staking address.  In the contract `Ownable` 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. 
The `PABLOToken` contract will transfer the collected fees to the owner address when the `PABLOStaking` is set to 0. Any compromise to the owner address may allow a hacker to transfer those tokens from the address, resulting in severe damage to the project.
All of the `PABLO` tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.
The `PABLOToken` contract will accumulate fees and then transfer the fees to owner address or `PABLOStaking`. This is a popular design for deflationary token. As for the collected fee, some deflationary tokens (e.g. Safemoon) adds it to to the liquidity pool to be locked forever. On the other hand, `PABLOToken` simply transfers those fees directly to `_owner` and `PABLOStaking` for unclear usage, thus adding to the centralization risk.
The change of `_owner` by function `transferOwnership()` overrides the previously set `_owner` with the new one without guaranteeing the new `_owner` is able to actuate transactions on-chain.
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=353 address public PABLOStaking = address(0); ``` - The contract `ERC20` interacts with third party contract with `PabloStake` interface via `PABLOStaking`.
| Address | Chain | Source code |
|---|---|---|
| 0x926f…1f470x926ff6584b5905cc793cfb19bfc0ad6443671f47 | Chain: Ethereum | Source code: Verified source |
| 0x89db…faaf0x89dbfd81c99cad2c6cb2c374a5622dd1135efaaf | Chain: Ethereum | Source code: Verified source |
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething 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