Prepared by:
HALBORN
Last Updated 02/24/2026
Date of Engagement: January 26th, 2026 - January 29th, 2026
100% of all REPORTED Findings have been addressed
All findings
13
Critical
1
High
3
Medium
7
Low
1
Informational
1
Rally Foundation engaged Halborn to perform a security assessment of their smart contracts from January 26th, 2026 to January 29th, 2026. The assessment scope was limited to the smart contracts provided to Halborn. Commit hashes and additional details are available in the Scope section of this report.
The Rally smart contract codebase implements a campaign-based reward system where brands deposit tokens into time-bounded campaigns, users earn rewards by completing Twitter missions evaluated by AI off-chain, and results are relayed back on-chain via a cross-chain bridge for users to claim.
Halborn was allocated 4 days for this engagement and assigned 1 full-time security engineer to conduct a comprehensive review of the smart contracts within scope. The engineer is an expert in blockchain and smart contract security, with advanced skills in penetration testing and smart contract exploitation, as well as extensive knowledge of multiple blockchain protocols.
The objectives of this assessment are to:
Identify potential security vulnerabilities within the smart contracts.
Verify that the smart contract functionality operates as intended.
In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of security risks, which were partially addressed by the Rally Foundation team. The main recommendations were:
Validate that the caller creating a campaign is the specified owner, and restrict bridge and registry to platform-controlled addresses.
Lock the bridge, authorized sources, and registry from modification once a campaign is funded.
Reject submissions and resubmissions to expired or terminated campaigns to prevent users paying for unrewardable actions.
Recalculate per-period token amounts from actual remaining balance after early termination to prevent insolvency.
Set campaign start time at funding rather than creation, or reject funding after the configured duration has elapsed.
Bind each tweet ID submission to the submitting wallet to prevent griefing by third parties.
Enforce submission fee token, amount, and minimum at the factory level rather than accepting caller-supplied values.
Validate authorized source chain IDs and contracts against a factory-maintained whitelist.
Reject zero addresses for critical parameters, verify token addresses are contracts, and enforce bounds on configuration values.
Restrict reward distribution to current and past periods only, rejecting future period indices.
Halborn conducted a combination of manual code review and automated security testing to balance efficiency, timeliness, practicality, and accuracy within the scope of this assessment. While manual testing is crucial for identifying flaws in logic, processes, and implementation, automated testing enhances coverage of smart contracts and quickly detects deviations from established security best practices.
The following phases and associated tools were employed throughout the term of the assessment:
Research into the platform's architecture, purpose and use.
Manual code review and walkthrough of smart contracts to identify any logical issues.
Comprehensive assessment of the safety and usage of critical Solidity variables and functions within scope that could lead to arithmetic-related vulnerabilities.
Local testing using custom scripts.
Fork testing against main networks.
Static security analysis of scoped contracts, and imported functions (Slither).
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
1
High
3
Medium
7
Low
1
Informational
1
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Post-termination reward calculation uses stale pot size causing guaranteed insolvency | Critical | Solved - 02/08/2026 |
| Mutable authorized sources enable cross-chain reward manipulation and selective denial of service | High | Risk Accepted - 02/17/2026 |
| Lack of sender binding on tweet ID submissions enables griefing of legitimate users | High | Risk Accepted - 02/17/2026 |
| Insufficient validation of caller-supplied parameters in campaign creation | High | Solved - 02/08/2026 |
| Unvalidated token addresses enable malicious and non-standard tokens | Medium | Risk Accepted - 02/17/2026 |
| Mutable bridge address enables post-funding rug pull | Medium | Solved - 02/17/2026 |
| Future period index accepted in reward distribution allows premature token allocation | Medium | Risk Accepted - 02/17/2026 |
| Absence of lower and upper bounds validation on campaign configuration parameters | Medium | Solved - 02/08/2026 |
| Caller-controlled owner parameter enables ownership griefing and phishing | Medium | Solved - 02/08/2026 |
| Unvalidated authorized source parameters across campaign lifecycle allow arbitrary cross-chain source injection | Medium | Risk Accepted - 02/17/2026 |
| Missing campaign lifecycle checks allow submissions to expired and terminated campaigns | Medium | Solved - 02/08/2026 |
| Missing zero address validation on critical address parameters | Low | Solved - 02/16/2026 |
| Single-step ownership transfer risks permanent loss of campaign control | Informational | Solved - 02/09/2026 |
//
//
//
//
//
//
//
//
//
//
//
//
//
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
Smart Contract Assessment
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed