Zealy integration breaks on manual task verification
Zealy integration rarely breaks at connection — it breaks at manual task verification. Anything that cannot be confirmed automatically — a subscription, a repost, a comment, participation in a community chat — comes down to a screenshot and a live moderator.
While there are dozens of tasks, this is tolerable; at a flow of several hundred submissions per day, verification becomes a bottleneck: confirmation stretches over hours, disputed cases pile up, and some rewards go to those who attached someone else's screenshot.
The second gap is in the data. Participant activity accounting lives in campaign exports, reward distribution in the moderator's spreadsheet, and community roles are assigned by a bot from a third list.
The desynchronization opens the door to point farming: duplicate accounts, the same screenshot in multiple tasks, self-referrals through one's own link.
By the time of the draw, no one can confirm that the top of the leaderboard consists of real participants, and the campaign loses its meaning.
We examine how this chain is closed: where action confirmation is replaced by verification of an on-chain event and stops depending on a screenshot, how activity accounting and point accrual are reduced to a single source, and reward distribution happens automatically — reprocessing the same event does not credit points twice, and only genuinely disputed cases remain with the moderator.
What changes after end-to-end reward automation
While accruals went through manual exports, the cycle looked like this: an employee took the list of activities from Zealy, reconciled wallet addresses with the transaction log, and entered points into the spreadsheet.
With a flow of hundreds of actions per day, this produced a delay of several hours and constant discrepancies between the registry and actual transactions.
After end-to-end automation, the share of manual operations drops from almost complete to a few percent — anomaly review and confirmation of disputed situations remain with humans.
Reaction time to a participant's action shrinks from hours to seconds: the transaction hit the network, verification passed, and points appeared in the personal account.
The unified points registry is built as an event log, not as an editable spreadsheet: a participant's balance is always recalculated from the log, so a discrepancy is resolved by re-running the accrual rather than by manual correction. Accruals themselves are idempotent — redelivery of an event does not double the points.
Anti-fraud protection is closed at the rules level: deduplication by transaction ID, accrual limits per address and per period, verification in the blockchain network before accrual.
Self-credits for transfers between linked wallets are filtered out separately — previously such cases were caught selectively and manually.
This directly affects retention: a participant sees the reward immediately after the action, not the next day, and does not leave to check whether they were credited at all.
The class of errors "forgot to accrue" and "accrued twice" disappears along with manual entry — disputed requests become several times fewer.
Zealy integration formats: comparison of approaches
The integration scheme is chosen not by how "modern" the approach is, but by the acceptable accrual delay and the cost of a missed action. For Zealy, four options work in practice, and each has a boundary beyond which it starts to cost more than it brings.
The key difference is who initiates the exchange: the external platform or our side.
Event notifications arrive on a participant's action, periodic polling queries state on a schedule, asset ownership verification confirms the presence of a token or role directly in the blockchain.
A hybrid scheme takes events for speed and scheduled polling as insurance against lost notifications.
| Option | When it fits | Limitations |
|---|---|---|
| Event synchronization | Accrual is needed within seconds after the action | Depends on notification delivery: a missed event cannot be recovered without reconciliation |
| Periodic polling | Non-critical delay, rare changes, a simple set of conditions | Load grows with polling frequency, state becomes stale between runs |
| Asset ownership verification | The condition is a token, role, or on-chain record | Requires a node or data provider; captures state at the moment of verification |
| Hybrid scheme | High requirements for completeness and speed at the same time | Harder to maintain: two logic branches, repeated accruals must be suppressed |
The choice of scheme comes down to two questions: what accrual delay is acceptable and what happens if a single action goes unnoticed.
Where a miss is unacceptable, we add blockchain reconciliation and protection against repeated accruals — otherwise the participant will receive the reward twice.
Implementation stages: from task audit to handover of regulations
The sequence of work is the same for a campaign with several hundred participants and for a program with a continuous flow of tasks.
First, we fix what counts as task completion, then design the chain, and only after that enable real accruals — this way disputed situations are resolved on paper, not in participants' wallets.
- Scenario audit. We go through the task list and divide tasks into automatically verifiable and those requiring manual confirmation. For each, we determine the source of truth — an on-chain transaction, wallet activity, or an event on the platform side.
- Integration scheme. We describe the data flow: where the request is signed, how Zealy confirms the participant's identity, and what goes into the retry queue when an external service fails.
- Chain setup. We bring up handlers, distribute keys and permissions, and enable logging of incoming events — every accrual must be explainable retrospectively.
- Test campaign. We run 5–10 tasks on a closed group: we check accrual, repeated invocation, cancellation, and a deliberately disputed result. A bug in the accrual logic is cheaper to find here than on a live audience.
- Work acceptance. We reconcile actual accruals with the log, check convergence using control wallets, and fix the criteria by which the campaign is considered delivered.
- Handover of regulations. We provide the scheme description, rules for handling disputed situations, instructions for connecting new tasks, and the procedure for when an external service is unavailable — ongoing support remains with your team.
Configurations, schemes, and regulations in the delivery
At the end of the work, the client is left not with a presentation but with a working environment: deployed configurations, schemes, policies, and documents according to which the integration can be operated and developed without our participation. Below is what exactly is handed over and in what form.
- Working integration configurations: mapping of Zealy quests to on-chain events, the set of verifiable conditions, accrual limits, and parameters of seasonal campaigns — as files that deploy identically in test and production environments.
- Data flow schemes: the path from a participant's action in Zealy to writing the result on-chain, with points for API calls, transaction verification, and reward accrual.
- Access policies: roles of service keys, scope of permissions for each, rotation periods, separation of read and write by contracts and campaigns.
- Description of accrual rules: a table "action → verification condition → reward → who resolves disputed cases", so the rules are read the same way by both the team and support.
- Operator instructions: how to launch a campaign, pause accruals, check a stuck transaction, and manually close a discrepancy.
- Support regulations: incident classes (external service unavailable, balance mismatch, signs of farming), response levels, escalation procedure, and data that must be attached to a request.
The documentation is tied to the live system, not to a report: configurations are stored in the client's repository, changes go through review, and instructions are updated together with campaign rules.
Case study: how campaign participant retention grew
The client is a Web3 project running a campaign on Zealy: subscription tasks, on-chain actions, and invitations. Points and roles were accrued manually by a moderator, reconciling wallets against a spreadsheet once a day.
A participant completed a task, saw no confirmation for a day, and left — by the middle of the campaign, churn became the main scenario. We examine what exactly was reworked and which measurements confirmed it.
What was changed
The campaign was linked to on-chain verification: the fact of the action is confirmed by a contract, not a screenshot. Point accrual and role assignment are triggered by an on-chain event, and only disputed cases go to manual review — fraudulent wallets and multiple accounts. The moderator stopped being a bottleneck: they process the exception queue, not the entire flow.
| Metric | Before | After |
|---|---|---|
| Share of automatic accruals | 38% | 96% |
| Reaction time to a participant's action | up to 18 hours | 3-5 minutes |
| Churn at the middle of the campaign | 41% | 15% |
| Retention until the end of the campaign | 27% | 58% |
How it was measured
Measurements were taken twice and from different sources: the first — from manual-mode logs at peak load, the second, independent — from on-chain events and accrual history after automation was enabled.
Comparability is ensured by the fact that the counting methodology did not change: the same actions and identical observation windows were counted.
The effect on the second wave was noted separately: participants who came through invitations reached the end more often — confirmation arrived instantly, and the inviter saw the result immediately.
The retention growth here is a consequence not of gamification as such, but of predictable feedback for every action.
How does verification through the interface differ from verification in the blockchain?
Verification through the interface is confirmation of an action on the task platform side: the scenario receives a signal about completion from the service, reconciles it with the rules, and writes the result to its own database.
Proof of completion remains inside the platform — participant ID, timestamp, task status. The blockchain does not participate in this chain, neither at the moment of the action nor when the reward is accrued.
Blockchain verification works differently: an engineer describes the condition in advance — a contract method call, the presence of a transaction, the token balance at an address — and the scenario reads the registry state directly.
Proof of completion here is public and immutable: it cannot be edited retroactively, and any participant can verify the same fact without contacting the platform.
The reward is issued by a transaction, so an accrual delay appears — it consists of the time to inclusion in a block and the required number of confirmations.
The key difference is what exactly is being confirmed. The interface covers off-chain actions: subscription, task completion, participant invitation, profile activity.
The blockchain covers on-chain actions: transfer, locking tokens in a contract, asset ownership, voting participation. There is no point in mixing methods without reason — confirmation lives where the fact itself arises.
The combined option is used when the action happens off-chain and the reward is on-chain: the platform records the event, a signer attests to it and sends a transaction, and Zealy together with the contract stores only the final record.
The boundaries are visible here too: interface verification breaks down when databases diverge and manual intervention occurs, while blockchain verification will not see an off-chain event without a trusted intermediary and costs more in waiting time.
Technical concerns before launching a campaign
Before launching a campaign, engineering questions are usually the same: where the keys are stored, what happens on restart, how tasks in multiple networks are counted, how quickly points are accrued, and who has access to the settings. Below are short answers for each point, as we handle it when working with Zealy.
How are access keys stored?
Keys are issued with the minimum required permissions: reading campaigns and writing results, without balance operations. Secrets are stored in a secure vault, signing is performed by a separate service, and there are no keys in the code or logs. If compromised, the key is revoked and changed without stopping the campaign.
What happens if the campaign is restarted?
Events are processed idempotently: each operation has an identifier, so a repeated run will not credit points twice. Participant progress and wallet bindings are preserved — stopping the campaign does not reset already completed tasks.
Will tasks in multiple networks break each other?
No, networks are verified independently: each has its own data source and its own confirmation threshold. Unavailability of one network does not block accruals in the others, and lagging verifications catch up after it returns.
How quickly are points accrued?
Confirmed transactions are picked up by events, with a typical delay from a few seconds to the network finality time. Bulk recalculations run in a queue so as not to hit platform limits on peak days.
Who on the team has access to the settings?
Access is role-based: an observer sees statistics, an operator edits tasks, an administrator manages keys and networks. Every change goes into the log — you can see who changed the conditions or verification thresholds and when.
Let's discuss the task and come back with an estimate and plan
To come back with a timeline estimate and work plan, a minimum set of initial data is needed. Below is what will be required from you at the start: without it, integration points have to be guessed, and timelines named blindly.
- Participant scenarios: which actions in the loyalty program need to be accounted for — quest completion, invitations, purchases, social media activity, holding a community role.
- Accrual rules: how many points per action, daily and monthly limits per participant, cancellation and recalculation conditions, crediting timelines.
- Roles and access: who administers the campaign, who moderates submissions, whether separate permission levels are needed for contractors and partners.
- Integration points: where the results go — to a database, accounting system, CRM, bot, or reward showcase — and what should be returned to the participant.
- Access to environments: workspace and key permissions in the gamification service, test environment, wallets for verifying accruals.
- Constraints: supported networks, identity verification policy, data retention requirements, participant geography.
- Acceptance criteria: how you will know that accrual and verification work correctly, and who on the client side signs off on the result.
Based on the description of scenarios and access, we assemble a work plan: connection order, scope of checks in the test environment, rollback points in case of accrual failure.
Let's discuss the task — we will come back with a timeline estimate and a plan where each stage is tied to a specific result.