VeloPass Labs. Keeping resale economics and venue access connected

Our work

We developed the ticketing infrastructure behind VeloPass Labs: controlled resale, organizer royalty accounting, ownership transfers and venue access. We connected the payment and ticket records to the credentials used at the gate, including the separate operating rules for online and offline admission.

A ticket can change hands several times between its first sale and the moment someone arrives at the venue. Each transfer can move revenue and the attendee relationship away from the organizer. Blocking resale entirely creates another problem. Fans whose plans change need a legitimate way to pass on their tickets. VeloPass Labs addresses that tension by making resale a controlled part of the ticket lifecycle, connected to payment, buyer eligibility and the credential accepted at the gate.

The project is enterprise ticketing infrastructure for organizers, venues and brands. Its architecture combines primary sales, programmable transfers, organizer royalties, identity checks and venue access beneath a conventional buying experience. The principal engineering challenge was making organizer participation part of a valid resale instead of a marketplace preference. The second was preserving fast admission when connectivity is unreliable, without pretending that disconnected scanners can always share the latest ownership and admission state.

The royalty needed to be part of the transfer path

Publishing a royalty percentage on a token does not make every marketplace pay it. The architecture uses ERC-2981 as an interoperability signal while placing enforcement in the ticket's transfer and settlement path. For an event configured as CONTROLLED_RESALE, a holder cannot use an ordinary unrestricted transfer to bypass the approved route. The TicketTransferController checks ownership, policy version, resale limits, buyer eligibility and settlement authorisation before completing the ownership change.

We separated the seller's listing from the transfer itself. A listing is an EIP-712 signed intent containing the ticket reference, price, expiry, policy version and seller nonce. Publishing it does not move the ticket. When a buyer accepts, the system rechecks current ownership and ticket state before settlement. A ticket that has been voided, admitted or placed under a relevant hold cannot rely on an earlier valid listing to escape those restrictions. Consumed nonces prevent the same authorisation from executing again.

The token model also has to preserve the identity of the entitlement being transferred. We used ERC-1155 for ticket classes and batch issuance, keeping individual seat entitlements distinct from the ticket class. The seat map and personal information remain off-chain. Contract state and policy commitments establish the transferable right without turning the public token record into a customer database. This keeps the resale mechanism applicable to both general admission and seat-specific products.

Controlled resale still has an important boundary. Two people can exchange money privately and attempt to use a permitted gift transfer. The platform cannot prove that no side payment occurred. Gifting therefore has its own policy, including limits, recipient checks, cooldowns or outright exclusion for a product. An organizer can also use a return-to-pool model where the platform reallocates the ticket to another eligible buyer. The enforceable decision is whether ownership may change through a particular route, not whether every economic arrangement outside the system can be observed.

Fiat payments required a different settlement model

We connected official resale to fiat checkout so buyers could pay without acquiring cryptocurrency. Card payment and ticket ownership then follow separate settlement steps. Card authorisation, capture, refunds and chargebacks have their own timing and failure modes. We kept the fiat path as a coordinated state machine rather than describing it as cryptographically atomic settlement.

The buyer's payment is authorised before transfer execution. A restricted signer produces a short-lived FiatSettlementAuthorization that binds the order, ticket, seller, buyer, price, royalty amounts, policy version and nonce. The signer acts only on payment state accepted by the payment service. It cannot change event policy, mint arbitrary inventory or upgrade contracts. After canonical ownership confirmation the flow proceeds to capture, royalty accounting and the scheduled seller payout. If transfer or payment processing fails, the order enters a compensation or refund workflow appropriate to the payment stage.

The settlement ledger records money independently from the order's display status. Balanced journal entries track PSP clearing, seller payables, organizer royalties, fees and refund obligations. Amounts use integer minor units and the applicable policy version stays attached to the transaction. Historical proceeds are not recalculated using today's fee configuration. Delayed seller payouts and chargeback reserves address exposure that cannot be eliminated merely by confirming a ticket transfer on-chain.

The stablecoin settlement path couples payment and ticket transfer in one transaction. The SettlementRouter validates the listing and buyer authorisation, calculates the split, transfers funds and invokes the controlled ticket transfer within one transaction. A failing contract check reverts the operation. The difference between these two payment models is deliberate. Both include organizer economics in the approved resale workflow, but only the on-chain path can couple payment and ticket transfer inside one EVM transaction.

Resale had to invalidate the seller's entry credential

Changing ownership is incomplete if the previous holder can still enter with a saved barcode. VeloPass Labs separates the durable entitlement from the short-lived credential used to present it at the venue. When a canonical transfer is confirmed the access service updates its ownership projection, revokes the previous credential family and activates a new presentation for the buyer. The access service pushes revocation updates to venue infrastructure. Online admission checks the current access ledger; offline scanners apply their last accepted verification package until an update arrives or its validity window closes.

This decision ties the marketplace directly to admission. A ticket is not fully handed over simply because a database row or token balance changed. We connected ownership changes to credential revocation and the new holder's entry-policy checks. Resale cutoffs near doors-open time help bound the operational gap between transfer confirmation and revocation propagation. Third-party wallet passes are presentation adapters too. If they cannot rotate barcodes as required, server-side revocation checks become part of the access path.

Organizer control depends on connecting the sale to the right the venue will accept. VeloPass Labs links resale policy, payment accounting, ownership and credential revocation so that an approved transfer carries its economic and operational consequences. The ticket lifecycle continues until the correct holder is admitted.

Purchase limits needed a fan identity beyond the wallet

A wallet address is not a reliable unit for limiting purchases. One fan can rotate devices or recover an account, while a reseller can create many addresses. The architecture therefore maintains a pseudonymous Fan ID separately from smart accounts. Purchase and transfer eligibility can depend on identity assurance, membership, presale credentials and event quotas. Personal source data remains off-chain and the contract receives only the necessary commitment or signed authorisation.

We built the fan sign-in around passkeys and an embedded smart account. Gas sponsorship follows the event and operation configuration. Higher assurance is requested when the event or action requires it rather than making every purchase begin with a document check. A short-lived purchase authorisation binds eligibility to the event, product, quantity, policy version and nonce. This narrows the decision from a general account approval to permission for a specific purchase context.

Anti-scalping controls operate before payment and minting. Queue tokens, device and session velocity, payment-instrument relationships, identity quotas and inventory-hold limits contribute different evidence. No single suspicious signal is treated as conclusive proof. Step-up verification and review states provide a response between unrestricted access and permanent exclusion. Account recovery follows the same principle. It can rotate authentication or replace a lost presentation credential without giving an ordinary support operator unilateral authority to move arbitrary tickets.

Gate decisions without a live chain query

A venue queue cannot wait for every scanner to query a public blockchain and resolve confirmation depth. The architecture assigns ownership truth to the ticket contract and operational admission state to a dedicated access ledger. A rotating QR or NFC presentation carries a signed event and entitlement reference, zone, holder commitment, validity window and nonce. The scanner verifies the signature and local constraints before asking the Access API for the current admission decision.

Online admission uses an atomic check-and-mark operation. The service confirms that the entitlement is active and has not been refunded, transferred away or already consumed for that access right. A successful response records admission and the scanner retains a signed receipt. This prevents two concurrent online scans from independently treating the same right as unused when they share the authoritative admission service. Rejection reasons distinguish an expired presentation from the wrong zone, an already admitted ticket or an unauthorised scanner.

We separated local signature verification, the access-service decision and revocation delivery. A scanner can verify a signature locally, while current ownership and prior admission come from the access ledger. Revocation propagation connects a completed transfer to venue equipment, with offline operation governed by the event policy.

Offline access required a bounded operating mode

Before an event, authorised scanners can receive an encrypted verification package containing event keys, relevant eligibility data, revocations, zone rules and an offline validity interval. During a WAN outage they verify signed presentations locally and append accepted scans to a local log for later synchronisation. A venue edge gateway can maintain a local admission ledger and exchange duplicate information between scanners over the venue network. The gate does not need to become a blockchain node to keep operating.

There is a limit that the design keeps explicit. Two fully disconnected gates cannot always know that the same credential has just been accepted elsewhere. Short credential lifetimes, zone partitioning, local networking and restricted offline windows reduce the exposure. They do not eliminate it across a complete partition. The event's offline policy therefore determines how long and under which conditions local acceptance is permitted. The event's resale and recovery rules account for delayed revocation delivery close to entry time.

Scanner identity is separate from ticket administration. Each device has an enrolled key scoped to its venue, event and gate assignments. That key cannot mint tickets, change resale terms or redirect payouts. Manual admission overrides require an authorised supervisor, reason and signed audit receipt. Lost-phone support can revoke an earlier presentation and issue a temporary venue credential after verification. These workflows make operational exceptions possible without turning a gate device into a general account-control tool.

High-demand sales and open gates needed separate capacity

A ticket drop and a live event create different load patterns. Checkout competes for scarce inventory while entry requires quick decisions about rights already issued. VeloPass Labs separates venue-critical traffic from commerce, control-plane operations and deferred work. We kept analytics exports and bulk CRM imports outside the capacity reserved for gate checks and revocation synchronisation. Asynchronous queues handle mint batches, payouts, notifications and integration retries where immediate completion is not required.

Primary sales pass through a waiting room with signed queue tokens before reaching inventory reservation. Short hold lifetimes and per-fan or device limits restrict how much inventory one actor can occupy. We separated temporary holds from durable inventory allocation. Concurrent checkout requests share a durable seat-allocation record, with allocation checks applied before a primary order is accepted. Redis accelerates reads and temporary holds; it does not serve as the sole durable record of final allocation.

Issuance and payment remain distinct transitions. Where the PSP supports it, authorisation precedes minting and capture follows durable issuance evidence. Batched minting can absorb high-volume demand when event policy permits a pending-chain state. The application records pending issuance separately from canonical ownership. Chain indexing tracks block references and confirmations so a reorganisation can trigger reconciliation before high-risk payout or transfer decisions proceed.

The organizer interface had to publish enforceable rules

The no-code console is the entry point for decisions that affect contracts, payments and scanners. We treated its output as a versioned policy rather than a collection of unrelated dashboard settings. The organizer sees a human-readable summary while the platform compiles the same configuration into machine rules. The on-chain registry stores a compact policy commitment and relevant transfer settings. Orders and authorisations reference the version that governs them.

We connected policy publication to checks across the ticket lifecycle.

• Validation checks resale windows and price caps.
• Settlement checks the combined royalty and fee split.
• Entry rules are matched to their verification path.
• Payout destinations pass through verification.
• Changes affecting active orders retain an explicit migration plan.

We included dual approval for high-risk changes under the event's policy. Payout changes, transfer-policy changes and event cancellation retain their approval and audit records. An event cancellation then coordinates resale locks, refunds, seller payout holds, ticket invalidation and access revocation. Changing ticket metadata alone would leave those obligations unresolved.

Attendance, ownership and marketing consent stay separate

A fan who bought a ticket and a fan who actually entered may be different people. The access ledger emits admission evidence that can become an AttendanceConfirmed event. Configured loyalty rules consume that event for points, attendance credentials and presale access. The points ledger records its source event and campaign version so rewards can be traced and corrected instead of existing only as a mutable total.

This keeps current ownership separate from the historical attendance record. Ownership transfers to the new holder, while historical attendance belongs to the person whose admission was confirmed. A portable credential can represent attendance without publishing legal identity or unnecessary seat details. Marketing consent remains a separate decision. Consent withdrawal leaves the ticket entitlement intact, and CRM availability is outside the entry decision. Loyalty processing and exports consume lifecycle events asynchronously rather than becoming dependencies of the scanner response.

Integration with existing ticketing systems

An enterprise organizer may already have inventory, checkout, payment and CRM systems it wants to retain. We kept the resale, issuance and access interfaces separate so integrations could retain the organizer's existing systems. Legacy records are imported with deduplication and reconciliation so adding a programmable entitlement does not create extra inventory. External IDs preserve the link to the existing system and the migration cutoff establishes which transfer rules apply.

Integration endpoints accept idempotency keys tied to the tenant and operation class. Repeating the same request returns the stored result, while changing its body under the same key produces a conflict. Webhooks use signed payloads, at-least-once delivery and consumer deduplication. Failed delivery enters a retry or dead-letter path rather than rolling back a completed transfer. This keeps partner availability separate from ticket ownership while retaining a way to repair downstream records.

We connected inventory, issuance, transfer policy, financial journals and admission records through the ticket lifecycle. Organizer royalties and seller liabilities retain their source transaction. A transfer updates the holder record and triggers credential replacement, while the access path applies the venue's connectivity and revocation rules.

The organizer can trace a ticket from inventory reservation through sale, resale and admission. Ownership history identifies who holds the entitlement; financial journals explain who is owed each payment; admission records show which credential was accepted. Loyalty and CRM integrations consume those events without becoming dependencies of the gate response.