Use Case: Targeted Coupon Campaign for Recent Luckin Customers

Version: v1.0 (Draft) Status: Draft Authoritative: Informative

Scenario

Luckin Coffee wants to run a promotional campaign in Singapore for users who have purchased from Luckin within the last 30 days.

The campaign goal is to identify up to 5000 eligible users and issue them coupons through downstream business systems.

This use case is informative. It shows how the revised SCP and SCS specifications map onto a concrete advertiser-driven audience-selection and coupon-distribution scenario.

Canonical protocol terms used here follow SCP Protocol Overview and SCP Core Spec.

Why This Use Case Matters

This scenario is useful because it demonstrates several important properties of the revised Symphony stack:

1. the requesting party is an advertiser rather than an end user
2. eligibility depends on protected purchase-history data inside Vault boundaries
3. the task includes geography, time-window, and audience-cap constraints
4. selection results must be verifiable before they become campaign-usable truth
5. coupon issuance remains downstream from finalized protocol accounting

It therefore shows how the protocol can support privacy-preserving marketing activation without turning raw consumer records into protocol-visible plaintext.

Entry Distinction

This scenario has two different layers:

1. business-side campaign intent
2. protocol-recognized eligibility and audience-selection work

The advertiser's desire to "send coupons to recent Luckin customers in Singapore" is not yet a full protocol event by itself. It becomes part of the SCP lifecycle only when the master node cluster admits a concrete authorized task with explicit targeting constraints.

Unlike the receipt-upload scenario, this use case involves:

1. a third-party advertiser accessing data that belongs to individual consumers across multiple enterprise nodes' Vaults
2. multi-Vault coordination where the master node cluster fans out execution to enterprise nodes and aggregates results
3. explicit data-subject consent for marketing usage scope
4. privacy budget consumption for audience-selection queries
5. TEE execution for cross-Vault eligibility evaluation on both enterprise nodes (per-Vault slices) and master nodes (secure aggregation)
6. result delivery to the advertiser's downstream campaign system

Protocol View

From the protocol perspective, this scenario transforms campaign intent into a verifiable and settleable audience-selection result.

1. Campaign Intent and Local Business Input

Luckin defines a campaign with these business constraints:

1. advertiser identity: Luckin Coffee
2. geography: Singapore
3. eligibility window: last 30 days
4. audience rule: users with recent Luckin purchase activity
5. audience cap: 5000
6. downstream outcome: coupon issuance

At this point, the campaign is still a business request, not protocol truth.

2. Task Admission, Consent Verification, and Constraint Binding

The system turns that request into authorized protocol work.

At a high level, admission establishes:

1. that the advertiser is authorized to submit the campaign
2. that the campaign has explicit policy and budget context, including monetary budget lock — the resulting TaskEnvelope carries a budget_lock_ref pointing to the SYM escrow on the Aptos chain
3. that the task is classified as task_class: query
4. that the geography and time-window constraints are fixed for this run
5. that the audience cap of 5000 is part of the protocol-evaluated task definition, not an advisory limit
6. that sufficient privacy budget is available for the query across participating Vaults

Before admission completes, the protocol also verifies:

1. that participating Vaults hold records from data subjects who have granted consent for marketing usage scope
2. that only consented records are eligible for the eligibility evaluation
3. that users who have withdrawn marketing consent are excluded regardless of purchase history

Only after this step does the campaign become protocol-recognized work.

3. Semantic Resolution, Derivation Rules, and Attribute Composition

Before any matching can happen, the task must be interpreted under the active semantic context.

That means the protocol must resolve what concepts such as these mean in the current domain and semantic_version:

1. Luckin purchase — a CanonicalAttribute in the commerce domain
2. purchase recency — derived via a DerivationRule of type threshold (purchase date vs. 30-day window), producing a boolean query attribute
3. Singapore eligibility — a CanonicalAttribute in the geography domain, either directly_queryable at city spatial resolution, or derived via a DerivationRule to coarser granularity
4. campaign audience membership — the composed result of the above attributes
5. coupon-targetable identity or contact handle — a CanonicalAttribute in the identity domain

This scenario requires a cross-domain AttributeComposition:

1. operator: AND
2. operand_attributes: [purchase_recency (commerce), singapore_eligibility (geography)]
3. combined_privacy_class: the higher of the two operand privacy classes
4. minimum_result_cardinality: a policy-defined threshold below which the result must be suppressed

The cross-domain derivation for purchase recency must reference the commerce domain purchase_date attribute with cross_domain_policy: allowed, since the geography domain is read-only in this composition.

This step matters because the revised SCP requires shared meaning, explicit derivation rules, and declared attribute composition before protected computation can be trusted.

4. Multi-Vault Coordination and Protected Eligibility Evaluation

Because purchase records are distributed across multiple Vaults, this task requires multi-Vault coordination as defined in the SCP Core Spec.

Coordination Envelope

The protocol creates a coordination envelope with:

1. participating_vault_ids: all Vaults that may hold relevant purchase records
2. minimum_vault_quorum: the minimum number of Vaults that must respond for the result to be valid
3. aggregation_method: union with cardinality cap, since the campaign seeks up to 5000 eligible users across all Vaults

Per-Vault Execution Slices

Each participating Vault independently:

1. checks local purchase history for Luckin activity within the last 30 days
2. evaluates the Singapore geography condition against local records
3. filters to only records where the data subject has granted marketing consent
4. produces a SliceResultBundle containing privacy-safe eligible-user signals, not raw purchase records

Each slice executes inside a TEE because the computation touches record material from Vaults that the advertiser does not operate. The TEE attestation report is included in the slice evidence.

Secure Aggregation and Audience Cap Enforcement

The Aggregation Runtime runs on a master node inside an attested TEE. The aggregation step:

1. combines per-Vault slice results without exposing which Vault contributed which users
2. enforces the audience cap of 5000 as a protocol invariant at the aggregation level
3. if more than 5000 users are eligible across all Vaults, applies the policy-defined selection logic (such as random sampling or recency-weighted selection)
4. if fewer Vaults than the quorum respond, the task is rejected rather than proceeding with incomplete coverage

Privacy Budget Consumption

1. each per-Vault slice consumes privacy budget for the affected data subjects under marketing usage scope
2. privacy budget consumption is recorded at execution time, before the aggregation result is formed
3. data subjects whose privacy budget for marketing is already exhausted are excluded from the query

Throughout this phase:

1. raw purchase history remains inside authorized Vault or TEE boundaries
2. the protocol relies on evidence, commitments, and replayable artifacts rather than unrestricted plaintext exposure
3. selection remains bound to the admitted campaign constraints
4. the advertiser never sees individual purchase records, only the final aggregate audience selection result

5. Verification and Accepted Audience Result

The protocol does not treat a candidate audience list as final truth immediately.

Instead, the eligibility result must be checked for correctness and integrity. In outcome terms, the result may be:

1. accepted
2. rejected
3. challenged

Only accepted work can continue into settlement.

6. Settlement, Accounting, and Coupon-Issuance Basis

If the result is accepted, it can enter settlement and become part of finalized protocol accounting.

In this scenario:

1. settlement turns the accepted audience-selection result into protocol-recognized campaign truth
2. finalized accounting becomes the basis for downstream coupon issuance
3. the locked SYM from the escrow is distributed according to the fee distribution formula — Data Contributors, Vault Operators, Executors, Verifiers, and Protocol Treasury each receive their policy-defined share
4. the actual coupon send remains a downstream business effect, not the source of protocol truth

The protocol therefore determines which audience result is trusted. Downstream systems determine how that trusted result is turned into issued coupons.

7. Result Delivery to the Campaign System

After settlement, the finalized audience-selection result must be delivered to the advertiser's downstream campaign system.

In this scenario:

1. the task submitter (Luckin as advertiser) is the authorized delivery recipient
2. the delivered result contains coupon-targetable contact handles or anonymized identifiers, not raw purchase records
3. delivery is recorded as a protocol-auditable event
4. the campaign system may then issue coupons based on the delivered result, but the protocol does not govern coupon delivery mechanics

Node-Level Execution

From the SCS perspective, the same scenario is realized through cooperating services distributed across two node types: master nodes (operated by the Symphony Foundation) and enterprise nodes (operated by approved enterprises).

The execution flow follows the path: User → Master → Enterprise (fan-out) → Master (aggregate) → Master (settle).

Master Node Services

1. API Gateway

The API Gateway on the master node cluster receives Luckin's campaign request. It terminates TLS, applies rate limiting, and routes the request to the Admission Plane services. The gateway is a routing and protection layer only — it does not perform protocol logic.

2. Admission Plane

The Admission Plane validates advertiser identity and authorization, verifies that consent and privacy budget are available across participating Vaults, resolves semantic context, and assembles the TaskEnvelope with the campaign constraints, budget_lock_ref, and coordination envelope. The task enters the accepted state.

3. Task Orchestrator

The Task Orchestrator receives the validated TaskEnvelope and drives the task through canonical state transitions (accepted → resolving → dispatched → verifying → awaiting_settlement → completed). Because this is a multi-Vault task, it delegates to the Multi-Vault Coordinator.

4. Multi-Vault Coordinator

The Multi-Vault Coordinator expands the coordination envelope into per-Vault execution assignments, sends each assignment to the target enterprise node, tracks per-Vault slice progress, enforces the quorum requirement, and triggers aggregation once sufficient slices have completed.

5. Aggregation Runtime (TEE)

The Aggregation Runtime runs inside an attested TEE on a master node. It receives per-Vault SliceResultBundle outputs, executes the declared union aggregation with cardinality cap, enforces the 5000-user audience limit, produces the aggregate result with cryptographic proof and AttestationReport, and purges per-Vault inputs after producing the aggregate.

6. Settlement Plane

The Settlement Plane verifies the aggregate result (including TEE attestation reports from each per-Vault slice and from the aggregation step), preserves replayable evidence, and finalizes settlement. On finalization, the Reward Accounting Service calculates per-actor reward shares and the Payout Service distributes SYM to recipients through the Reward Contract on Aptos.

Enterprise Node Services

Each enterprise node independently performs the following within its own Vault boundary:

1. Authorization and Consent Verification

The Vault services verify that the incoming execution assignment is authorized, that data subjects in the local Vault have granted consent for marketing usage scope, and that sufficient per-subject privacy budget remains. Users who have withdrawn marketing consent or whose privacy budget is exhausted are excluded before any computation begins.

2. Computation Runtime (TEE)

The Computation Runtime evaluates the eligibility conditions — Luckin purchase recency, Singapore geography, and consent — against authorized records inside the Vault or TEE boundary. It produces a SliceResultBundle containing privacy-safe eligible-user signals (not raw purchase records), with commitment-linked, deterministic output and TEE attestation evidence.

The SliceResultBundle is returned to the master node cluster for aggregation.

Economic Flow

This section traces how SYM moves through the protocol during this campaign.

Budget Lock

Before the task enters admission, Luckin (as Task Submitter) locks SYM in the Escrow Contract on Aptos. The locked amount is calculated from the query pricing formula:

query_fee = base_fee_query
          + (n_vaults × per_vault_fee)
          + (n_records_returned × per_record_fee)
          + (epsilon_consumed × per_epsilon_fee)

All fee parameters are set by the active policy_version. The TaskEnvelope carries a budget_lock_ref pointing to this escrow. The task cannot be admitted without a confirmed escrow lock.

Fee Distribution on Settlement

When the task completes and settlement is finalized, the locked fee is distributed as:

Recipient	Share	Basis
Data Contributors	30-50%	proportional to records used and privacy budget consumed against their data
Vault Operators	15-25%	proportional to records served and storage commitment
Executors	15-25%	proportional to verified compute work (per-Vault slices and aggregation)
Verifiers	5-10%	per verification decision
Protocol Treasury	5-10%	fixed protocol fee for sustainability

Exact percentages are set by the active policy_version. The sum equals 100% of the locked fee.

Data Usage Dividends

Data Contributors whose records were included in the eligibility evaluation receive data usage dividends from the Data Contributor share:

1. distribution is proportional to the number of records used per Data Producer, weighted by privacy budget consumed against their records
2. staked Data Producers (those who have deposited S_producer SYM) receive 100% of their calculated dividend
3. unstaked Data Producers receive 50% — the remaining 50% is returned to the epoch reward pool
4. dividend attribution uses Vault-internal accounting so that the coordination layer never sees which specific Data Producer's records were used

Payout Execution

All distribution is executed through the Reward Contract on Aptos:

1. the Reward Accounting Service on the master node cluster produces per-actor reward records
2. the Payout Service transforms those records into a PayoutInstructionSet and submits it to the chain
3. the Reward Contract distributes SYM to recipients, applying the staking multiplier
4. payout records are per-epoch, append-only, and reconcilable against on-chain state

Semantic and Eligibility Handling

This scenario is also a good example of governed semantic interpretation.

If the campaign depends on concepts that do not map cleanly to the active canonical set, several things may happen:

1. the task may remain blocked until the semantics are clarified
2. some concepts may stay local under policy-permitted handling
3. emerging campaign or audience concepts may later contribute to governed semantic evolution

This is where the use case touches:

1. domain
2. CanonicalAttribute
3. local attribute handling
4. governed candidate evolution

The important point is that campaign logic does not get to redefine protocol meaning privately or silently.

Settlement and Coupon Issuance Consequences

This use case does not mean that Luckin automatically receives protocol rewards.

Instead, the main protocol consequences are:

1. a trusted, accepted, and settled audience-selection result
2. a finalized accounting basis for downstream coupon issuance
3. recorded privacy budget consumption for all data subjects whose records were evaluated
4. TEE attestation evidence preserved in the settlement context

If the campaign operates inside a rewarded network path, reward consequences may also exist for production roles such as:

1. Vault operators who served authorized data access
2. executors who performed TEE-attested eligibility evaluation
3. verifiers who validated the aggregate result

Those consequences remain downstream from protocol-recognized state transitions.

Key Boundary Reminders

The campaign brief itself is not yet a full protocol event.

The full SCP lifecycle begins only when the system turns that business intent into authorized protocol work with explicit audience, location, and recency constraints.

Likewise, the coupon send itself is not the protocol truth. The protocol truth is the accepted and settled audience-selection result that downstream systems then act upon.

This use case demonstrates the full complexity of the protocol: multi-Vault fan-out and aggregation across master and enterprise nodes, third-party data-subject consent verification, TEE-attested execution on both enterprise nodes and master nodes, privacy budget consumption, audience cap enforcement at the aggregation layer, SYM escrow and fee distribution through Aptos smart contracts, and result delivery to a downstream business system. It is the reference scenario for understanding how SCP governs cross-Vault query work under privacy and economic constraints.