Nexalo: Making Raffle Purchases Atomic

The answer in 30 seconds

Nexalo directly engaged Zealynx to review an autonomous on-chain raffle protocol built from six Solidity contracts. The reviewed system combined ticket purchases, NXL reward allocation, Chainlink VRF winner selection, referrals, staking, vesting, and treasury operations at commit da7c925bec3b3927aa3c88738a1f1b7375d1c887.[1][2]

The pivotal issue was transaction ordering. buyTickets() and buySpecificTickets() accepted payment and assigned tickets before attempting NXL reward distribution. If the NXL pool was exhausted, the code caught the reward failure and deactivated the product instead of reverting the purchase. That could leave a paid, incomplete round unable to accept more tickets or reach VRF settlement. Zealynx reframed the path around purchase atomicity, reported the Critical issue, and recommended validating reward capacity before changing purchase state. The report records the issue as fixed by Nexalo and verified by Zealynx.[1]

This is a technical engagement narrative based on public provider-authored evidence, not a customer transformation story. It does not claim exploitation, production deployment, monetary exposure, customer sentiment, or continuing assurance.

The buyer decision: what must succeed together?

Nexalo's reviewed design offered six raffle products with numbered ticket purchases, proportional NXL allocations, Chainlink VRF draws, and multi-stakeholder fund distribution. The scope covered approximately 1,150 normalized lines across NexumManager, ReferralNetwork, AmbassadorRegistry, NXLToken, NexaloStaking, and TreasuryBTC.[1][2]

For a raffle or GameFi founder, the decision is: before accepting a purchase, which dependent operations must be available so the protocol can still finish or unwind the round?

The relevant invariant was:

A ticket purchase must either complete payment, ticket ownership, reward allocation, and the resulting round transition together, or leave all purchase state unchanged.

A successful token transfer is not enough. The transaction is safe only if every state change required for the round's future settlement remains coherent.

The dangerous assumption: catching a failure makes the purchase safer

The reviewed purchase path performed economically meaningful actions before NXL distribution: it accepted stablecoin payment and assigned tickets. When reward distribution failed because NXL was exhausted, a try/catch path handled the exception by deactivating the raffle product.[1]

That error handling prevented the reward failure from reverting the earlier state changes. The report's sequence was:

1. the NXL reward pool becomes exhausted or nearly exhausted;
2. a buyer calls a ticket-purchase function;
3. the protocol accepts payment and assigns tickets;
4. NXL distribution fails;
5. the catch path deactivates the product;
6. later purchases revert because the product is inactive;
7. the incomplete round cannot sell enough tickets to request VRF randomness and select a winner.[1]

The dangerous assumption was that graceful degradation at one subsystem boundary would preserve the wider workflow. In this state machine, catching the failure converted a revertible purchase into a persistent partial purchase.

How Zealynx tested the purchase invariant

1. Trace effects across the complete purchase path

The review followed stablecoin payment, ticket ownership, NXL distribution, product status, ticket-count thresholds, VRF request eligibility, and winner selection as one connected lifecycle rather than reviewing each call in isolation.[1]

2. Force the finite dependency to its boundary

NXL rewards were not an unlimited dependency. Zealynx tested what happened when reward capacity reached exhaustion, including the first purchase that crossed the boundary and every purchase attempted afterward.[1]

3. Distinguish a reverted call from a caught call

A reverting dependent call can unwind earlier state changes in the same transaction. A caught failure does not do that automatically. The review checked which payment and ticket effects persisted after _distributeNXL() failed and _handleNXLExhaustion() ran.[1]

4. Follow the resulting state to settlement

The review did not stop at “reward distribution failed.” It asked whether the remaining round could still reach its ticket threshold, request VRF randomness, select a winner, or refund participants. The report records that the deactivated product blocked subsequent purchases and that no recovery mechanism existed for the incomplete round.[1]

The pivotal discovery: local recovery broke global liveness

The catch path recovered control flow locally, but it broke the round's global liveness. Payment and ticket assignment persisted, while the state transition needed to complete the raffle became unreachable.[1]

The core lesson is that error handling is part of the state machine. A caught exception is safe only when the post-catch state still satisfies every economic invariant and liveness requirement.

Before, intervention, and verified after-state

“Fixed and verified” is limited to the reviewed remediation recorded in the December 2025 report. The public evidence does not identify a final remediation commit or establish that the corrected code was deployed.[1]

A reusable atomicity model for multi-step purchases

For any purchase that depends on inventory, rewards, randomness, referral accounting, or settlement capacity, classify each operation before writing state:

preconditions = payment asset allowed
              + product active
              + inventory available
              + reward capacity available
              + settlement path reachable

if any required precondition is false:
    revert before payment or ownership state changes
else:
    commit the purchase as one coherent transition

Before launching or changing a raffle purchase flow, verify:

1. Precondition ordering: Are finite dependencies checked before payment and ownership change?
2. Failure semantics: Does every required downstream failure revert the whole purchase?
3. Catch-path state: If a failure is intentionally caught, which earlier effects persist?
4. Round liveness: Can every reachable round still close, settle, cancel, or refund?
5. Deactivation behavior: What happens to active rounds when a product is paused or exhausted?
6. Inventory boundaries: Are reward and ticket capacities tested at zero, one below, exact, and one above the limit?
7. External-call behavior: Can non-standard token behavior or callback failure create a partial purchase?
8. Recovery controls: Is any recovery path explicit, access-controlled, and tested without taking active-round funds?

Impact and evidence limits

The strongest supportable result is finding-specific: the report documents a Critical purchase-ordering flaw that could leave stablecoin payments in an incomplete raffle round after NXL exhaustion, and it records the issue as fixed and verified.[1]

The wider review reported 22 findings: three Critical, five High, ten Medium, and four Low. The public audit record reports 14 fixed and eight acknowledged findings.[2] This narrative does not turn those statuses into a claim that the entire protocol was secure.

No public source establishes that the affected contracts were deployed, that a real purchase entered the documented state, or that a dated amount of assets was exposed. No TVL, funds-protected, money-saved, loss-avoided, or business-outcome claim is made.

Evidence and attribution

• Canonical technical record: the Zealynx report identifies Nexalo, the reviewed contracts and commit, the purchase-ordering mechanism, the recommended validation change, and C-02's fixed-and-verified status.[1]
• Public audit record: Zealynx's engagement page reports the same scope, finding distribution, direct review team, and aggregate remediation state.[2]
• Attribution class: direct Zealynx engagement. The public Zealynx report identifies Zealynx as the audit provider and contains no partner-delivery attribution.
• Evidence cutoff: the December 2025 report and the public audit page retrieved for this narrative.
• Limitations: provider-authored evidence supports technical scope and recorded remediation, but not deployment, customer sentiment, commercial impact, exploitation, or later-code security.

Building a purchase flow with dependent rewards or settlement?

Zealynx can test whether payment, inventory, ownership, rewards, randomness, cancellation, and settlement remain atomic across success and failure boundaries. Explore smart contract security audits or request a transaction-lifecycle review.

Frequently asked questions

Why did try/catch create risk here?

The catch path allowed the transaction to continue after reward distribution failed. Earlier payment and ticket-assignment effects could therefore persist while product deactivation prevented the round from reaching its normal settlement threshold.[1]

What should have been checked before accepting payment?

The report recommended explicit state validation for NXL reward availability instead of relying on the existing catch behavior. More generally, every finite dependency required to complete the purchase should be validated before economic state changes are committed.[1]

Was the issue fixed?

The report records Nexalo's response as fixed and Zealynx's verification as “Verified. Fixed.” The evidence does not identify a final remediation commit or prove deployment.[1]

Were all Nexalo findings fixed?

No. The public audit record reports 14 fixed and eight acknowledged findings across the wider review.[2] This case study focuses only on the fixed purchase-atomicity issue and does not imply complete protocol security.

Was this a direct Zealynx engagement?

Yes. The public report identifies Zealynx as the provider of the independent Solidity security review and contains no partner-delivery attribution.[1]

How much value did the review protect?

The public evidence provides no dated, scoped asset amount for the affected purchase path. This narrative therefore makes no monetary exposure, value-protected, money-saved, or loss-avoided claim.

Sources

[1] https://raw.githubusercontent.com/ZealynxSecurity/audits/main/web3/2025-12-zealynx-nexalo.pdf — Nexalo Smart Contract Audit [2] https://zealynx.io/audits/nexalo/raffle-protocol-q4-2025 — Nexalo Smart Contract Audit Record