How QuillAudits Helped HeyElsa Secure Its Protocol Ahead of the $1M Agentic Fellowship Launch

HeyElsa is an AI-powered on-chain execution and staking platform focused on simplifying how users and builders interact with crypto applications. The protocol combines intelligent agent infrastructure, staking mechanics, and reward systems to support autonomous onchain actions, user participation, and ecosystem growth. Through initiatives like its $1M Agentic Fellowship, HeyElsa is building an ecosystem for developers creating revenue-generating onchain AI agents, while prioritizing secure, scalable, and user-friendly Web3 infrastructure.

From Vulnerabilities to Verifiable Security: Securing HeyElsa

HeyElsa is a staking and governance protocol built around a vote-escrow mechanism where users lock ELSA tokens to receive veELSA, representing time-weighted voting power that decays linearly over time. The protocol enables users to stake across multiple tiers with varying reward structures, while applying slashing penalties for early withdrawals. veELSA powers core ecosystem functions including governance participation, Season 1 reward distribution through TVL-scaled emissions, and eligibility for ecosystem airdrops.

heyElsa’s Journey Through Our Audit Process

1. Client Onboarding & Scoping
   • Collected asset list, defined in-scope and out-of-scope targets, agreed on testing windows, and signed NDA, MSA, and Authorisation Letter before engagement began.
2. Requirement Gathering
   • Completed a full-stack technical questionnaire and produced an architecture overview, API specs, and authentication flow diagram.
3. Kickoff Meeting
   • Walked through all in-scope assets with client engineering, validated credentials across all role tiers, confirmed staging mirrors production, and ran a smoke test against key endpoints.
   • Established real-time communication channel, defined a critical severity escalation path, and locked the testing and delivery timeline.
4. Reconnaissance & Threat Modelling
   • Conducted passive and active recon, including subdomain enumeration, port scanning, JS bundle analysis, and secret scanning.
   • Applied STRIDE threat modelling across all components, mapping DApp-specific attack vectors.
5. Manual Security Testing
   • Tested authentication and authorization flaws — JWT attacks, SIWE bypass, RBAC escalation, and OAuth2 vulnerabilities.
   • Tested API abuse — IDOR, mass assignment, rate limit bypass, GraphQL attacks, and WebSocket hijacking.
   • Tested frontend vulnerabilities — XSS, malicious wallet injection, clickjacking, and missing SRI on CDN scripts.
   • Tested backend flaws — SSRF, signature replay, injection, deserialization, and SSTI/RCE.
   • Tested Web3-specific vectors — RPC key leakage from JS bundles, chain spoofing, ENS/oracle manipulation, and Subgraph abuse.
   • Tested infrastructure — secrets leakage, S3 misconfigurations, container security, and CI/CD pipeline vulnerabilities.
6. Automated Scanning
   • Ran Nmap, Nessus, Burp Suite Pro, OWASP ZAP, GraphQL Cop, Arjun, ScoutSuite, Prowler, and Trivy for comprehensive vulnerability and misconfiguration coverage.
7. Vulnerability Analysis & Exploitation
   • Deduplicated all findings, scored each using CVSS v3.1, developed proofs-of-concept, and classified them by severity with defined disclosure timelines.
8. Reporting & Remediation
   • Drafted a full technical report with per-vulnerability detail, reproduction steps, remediation guidance, and a prioritised fix roadmap.
   • Reviewed client fixes, re-executed PoCs, and classified each finding as Fixed, Partially Fixed, or Open.
9. Final Delivery
   • Delivered full technical report, executive summary, evidence archive, and Certificate of Audit — all transmitted encrypted via PGP.
   • Conducted a handover meeting with root cause walkthroughs and a 30-day post-engagement support window.

QuillAudits' Strategic Approach to heyElsa’s Security Audits

Our approach to auditing heyElsa’s combined a security-first mindset, comprehensive threat modelling, and rigorous testing methodologies. By leveraging both white-box and black-box testing techniques, we conducted an in-depth assessment of the system. Throughout the process, we maintained transparency and clear communication with the heyElsa team, ensuring a collaborative and thorough security review.

Comprehensive Audit Discoveries and Remediation Strategies

• High Severity Issues (2): Critical vulnerabilities impacting staking fairness, reward integrity, and protocol accounting.
• Medium Severity Issues (5): Risks related to reward solvency, gasless authorization, and reward claiming mechanisms.
• Low Severity Issues (4): Minor logic and accounting inconsistencies affecting usability and transparency.
• Informational Severity Issues (13): Best-practice improvements focused on monitoring, admin controls, and protocol maintainability.

Here is a breakdown of the key vulnerabilities identified during the security assessment of HeyElsa and the remediation strategies implemented by QuillAudits:

Audit Findings:

1. Frontrunnable Stake Index Reordering Can Cause Unintended Early-Unstake Penalties

   “The staking system relies on user-supplied array indices to identify specific stake positions during withdrawal via unstake(uint256 stakeIndex). However, the cleanupInactiveStakes(address) function can be called by any external user and performs in-place array compaction by shifting active stakes forward and removing inactive ones.”

2. Time-Based Reward Accrual Is Not Bounded by Reward Pool, Leading to Severe Reward Insolvency

   “The reward accounting system accrues rewards purely based on elapsed time and staking rate, without enforcing a hard upper bound tied to the actual size of the rewardPool. As a result, rewards continue to mathematically accrue even when the protocol does not have sufficient funds to cover them.”

3. Gasless Staking Authorization Is Frontrunnable, Allowing Tier Manipulation

   “The stakeWithAuthorization() function allows gasless staking using receiveWithAuthorization, where a user (from) signs an authorization permitting token transfer. However, the signed authorization does not bind the tierId parameter, which is supplied by the transaction sender at execution time.”

4. Lack of Partial Reward Claims Can Permanently Lock User Rewards

   “The claimRewards() function enforces an all-or-nothing reward claim model, requiring that a user’s entire pending reward balance be paid out in a single transaction. If rewards[msg.sender] exceeds the available rewardPool, the call reverts and no rewards can be claimed at all.”

5. Asymmetric eligibility-window guard inflates the eligible ve denominator and permanently dilutes honest staker’s rewards

   “VotingEscrow exposes three sister entry points for changing a lock: _depositFor (used by depositFor), _increaseAmount (used by increaseAmount), and _increaseUnlockTime (used by increaseUnlockTime and increaseAmountAndTime). Two of those three reject any mutation by a seasonEligible user once the eligibility window has closed the third does not.”

Recommendation:

1. Frontrunnable Stake Index Reordering Can Cause Unintended Early-Unstake Penalties

   “Limit calls to the stake owner (msg.sender == account).”

2. Time-Based Reward Accrual Is Not Bounded by Reward Pool, Leading to Severe Reward Insolvency

   “Accrue rewards only when rewards are explicitly funded (e.g., epoch-based funding or discrete reward injections).”

3. Gasless Staking Authorization Is Frontrunnable, Allowing Tier Manipulation

   “Include tierId in the signed payload so that it cannot be altered at execution time.”

4. Lack of Partial Reward Claims Can Permanently Lock User Rewards

   “Permit users to claim up to min(rewards[user], rewardPool) and leave the remainder accrued.”

5. Asymmetric eligibility-window guard inflates the eligible ve denominator and permanently dilutes honest staker’s rewards

   “Add the three-line guard mirroring the exact pattern used in _increaseAmount and depositFor”

Conclusion

The audit uncovered critical weaknesses across authentication, wallet interactions, and claim logic—areas that sit directly on the path of user funds.

By addressing these issues, heyElsa eliminated multiple real-world attack vectors that could have led to unauthorised claims, account compromise, and fund loss. The fixes not only strengthened security but also restored the core guarantees of ownership and trust that Web3 systems rely on.

This engagement highlights a key reality: in Web3, even small gaps in validation or access control can turn into high-impact exploits. Proactively identifying and fixing these issues before production significantly reduced heyElsa’s risk surface and positioned the platform for a more secure launch.