# PDV Whitepaper

**Blockchain-ready access control for real venues**

| | |
|---|---|
| **Project** | PDV — Access Control System |
| **Entity** | PandaV Enterprise (TR0300693-M), Malaysia |
| **Website** | https://www.pandav.io |
| **Version** | 3.0 — access-control only |
| **Date** | June 2024 |

---

## 1. Abstract

PDV is a **multi-merchant access control SaaS** that connects physical doors to blockchain credentials.

Merchants create access products, mint **Access NFTs**, issue digital keys to visitor wallets, and open doors through industry Wiegand controllers. Door events are logged for audit. Ownership of credentials can be verified on-chain.

The system is **DB-first for door speed** (CardNO / QR privilege) and **chain-backed for ownership** (mint, transfer, burn). It is built for real venues — offices, events, clubs, campuses — and is open to further Web3 features and other chains through partnership.

---

## 2. Problem

Traditional access control is:

- **Centralized** — card numbers live only in a vendor database; ownership is hard to prove or transfer.
- **Opaque** — visitors cannot independently verify what they hold; operators cannot easily prove issuance history.
- **Siloed** — each site is a closed system; tickets, identity, and door hardware do not share a common credential layer.

Many “NFT ticket” demos stop at an image and a QR on a phone. They rarely integrate **real door controllers**, **multi-merchant operations**, and **verifiable on-chain credentials** in one product.

PDV closes that gap: hardware that works today, credentials that can live on-chain.

---

## 3. Solution overview

```
  Visitor wallet                 Merchant Admin                 Platform Admin
         │                              │                              │
         │  Access NFT / QR             │  Products · Cards · Door     │  Merchants · ops
         ▼                              ▼                              ▼
                    PDV Access API
                              │
           ┌──────────────────┼──────────────────┐
           ▼                  ▼                  ▼
        Database         Blockchain node      Door controller
     tickets / logs    mint · transfer      privilege ·
                       burn                 remote open · swipe
```

### 3.1 What ships today (Version08)

| Layer | Role |
|-------|------|
| **Platform** | Shared issuer infrastructure; onboard merchants; ops tools |
| **Merchant** | Access products, inventory generate, issue/assign cards, door settings, wallet bind, entry logs |
| **Visitor** | Wallet login, my access cards/tickets, self-register via merchant QR, scan-window QR for door |
| **Hardware** | WG (Wiegand) 1001 CloudServer — privilege, remote open, swipe sync; **ESP32 / ESP** door & QR bridges |
| **Chain (current)** | Access NFT mint / transfer / burn on Ergo |

### 3.2 Design principles

1. **Door first, chain async** — opening a door must not wait on block confirmation. CardNO privilege and remote open are immediate; mint/transfer run asynchronously where needed.
2. **Multi-tenant SaaS** — one shared stack, many merchants, JWT + API Key isolation.
3. **Auditable** — hardware swipe logs plus settled entry records, with optional on-chain transaction references.
4. **Blockchain-ready, not chain-locked** — Ergo is the current production chain; the access model is designed so other chains can be added later through partnership.

---

## 4. Actors and roles

| Role | Who | Primary actions |
|------|-----|-----------------|
| **Platform admin** | PDV operators | Create merchants, rotate API keys, inspect mint/burn |
| **Merchant owner / staff** | Venue / event operators | Bind wallet, manage products & cards, configure door, approve visitor registrations |
| **Visitor** | Card / ticket holders | Login with wallet, receive Access NFT credentials, show QR / scan window |
| **Integrator** | External POS / booking | Call `api/v1` with merchant API Key (issue cards, list products) |
| **Door controller** | 1001 CloudServer / ESP32 bridges | Enforce privilege windows; QR / swipe paths |

---

## 5. Product flows

### 5.1 Merchant onboarding

1. Platform creates merchant account and optional API Key.
2. Merchant logs into Admin, sets company profile and door controller (IP / SN).
3. Merchant binds a wallet for credential issuance flows.
4. Merchant configures products and door modes.

### 5.2 Inventory: generate → issue

1. Merchant creates an access **product** (event / membership / visitor pool).
2. **Generate** — allocate Wiegand-safe **CardNO** → mint Access NFT → card `Available`.
3. **Issue / assign** — attach visitor wallet → card `Assigned` → **async** NFT transfer to visitor.
4. Door privilege is **not** always standing; merchant can enable **scan window** (~5s) or **standing privilege**.

### 5.3 Open door (two paths)

**A. Remote / operator scan**  
Merchant (or integration) posts CardNO → validate → remote open → log entry.

**B. On-site QR**  
Visitor activates scan window → QR / privilege on 1001 → physical swipe → Admin/API syncs swipes → Pass recorded.

Door modes: online / always-open / always-closed + open delay (WG JSON-RPC).

### 5.4 Visitor self-register

Merchant displays a register QR. Visitor scans in app, submits profile (+ selfie if required). Merchant approves or auto-assigns spare cards.

### 5.5 Lifecycle controls

Block / unblock · validity edit · auto-expire · burn unused inventory · transfer credentials between wallets (visitor).

---

## 6. Technical architecture

### 6.1 Stack

| Component | Technology |
|-----------|------------|
| API | ASP.NET Core 8, JWT Bearer + `X-Api-Key` |
| Database | Microsoft SQL Server |
| Admin | React + Vite (platform + merchant console) |
| Visitor app | Capacitor / React (wallet-centric client) |
| Chain (current) | Ergo node wallet API — mint, transfer, burn |
| Door | WG 1001 CloudServer (Wiegand) + ESP32 / ESP door & QR bridges |
| Wallet UX | ErgoAuth / ErgoPay-style signing sessions |

### 6.2 Credential model

- **CardNO** — numeric credential compatible with Wiegand26-style readers; encoded into plain or encrypted QR.
- **Access NFT** — on-chain credential minted by the platform issuer; ownership tracks who *should* hold the key.
- **Binding** — each access record links `CardNO` ↔ `TokenId` ↔ `VisitorWallet` ↔ merchant / product / validity.

DB is authoritative for **can this CardNO open now?**  
Chain is authoritative for **who owns the Access NFT?**

### 6.3 Security notes

- Merchant and platform auth via JWT; integrations via API Key.
- Wallet bind and credential actions use cryptographic wallet interaction where required.
- Door privilege windows limit replay of static QR.
- Hardware and chain can be mocked for development; production uses live node + 1001.

---

## 7. Blockchain role (credentials only)

Blockchain is a **credential layer** for the access control system — not the product itself.

| Capability | Why it matters for access |
|------------|---------------------------|
| **Access NFTs** | Portable, transferable proof of a ticket / key |
| **Wallet login** | Cryptographic identity for visitors |
| **Auditability** | SaaS door logs + optional on-chain ownership history |

**Current network:** Ergo.  
**Open path:** other chains and adapters via partnership (see §11).

---

## 8. Use cases

| Segment | How PDV fits |
|---------|-----------------|
| **Events & venues** | Issue NFT access tickets; scan at door; transfer tickets |
| **Membership clubs** | Standing privilege cards; audit logs |
| **Offices / campuses** | Visitor self-register QR; temporary scan windows; remote open for reception |
| **Integrators / POS** | API Key issue from booking or POS partners |
| **Multi-site operators** | Multi-merchant SaaS — one platform, many door endpoints |

---

## 9. Competitive position

| Approach | Gap | PDV |
|----------|-----|--------|
| Classic ACS | No wallet ownership of credentials | Hardware-compatible + chain ownership |
| NFT ticket marketplaces | Rarely talk to real Wiegand doors | 1001 privilege + swipe settlement |
| Generic “Web3 access” demos | Single tenant / mock doors | Multi-merchant SaaS + real door path |
| Pure on-chain gate | Too slow / fragile at the door | DB-first open + async chain |

---

## 10. Roadmap

### Delivered (Access SaaS)

- [x] Multi-merchant API + Admin console  
- [x] Product → generate (mint) → issue (async transfer)  
- [x] CardNO QR, scan window, standing privilege, block/expire/burn  
- [x] WG 1001 remote open + swipe sync  
- [x] ESP32 / ESP door & QR reader path  
- [x] Merchant wallet bind  
- [x] Visitor wallet auth, my cards, self-register  
- [x] Integration surface (`api/v1`)  

### Near term

- [ ] Hardening visitor app UX  
- [ ] Persist wallet sessions beyond API memory  
- [ ] Merchant Staff role permissions in Admin UI  
- [ ] Public marketing site rebuild  
- [ ] Operator docs + integrator guide  

### Later

- [ ] Broader hardware adapters beyond 1001  
- [ ] Deeper POS / ticketing partner kits  
- [ ] Additional access-related Web3 features  
- [ ] Multi-chain credential adapters via partnership  

---

## 11. Partnerships & multi-chain openness

PDV is open to partnerships that extend the **access control** product:

- Door / ACS vendors, ESP32 installers, and integrators  
- POS, booking, and ticketing platforms  
- Wallet and identity providers  
- Teams who want credentials mirrored or issued on **other chains**

The access model (CardNO + ticket lifecycle + merchant SaaS) is chain-agnostic at the product layer. Ergo is the first production backend; **other chains are welcome through collaboration**.

---

## 12. Team

| Member | Role | Background |
|--------|------|------------|
| **Hero Koo** | Founder | Security systems (alarm, CCTV, door access, auto-gate, networking); FinTech experience; community builder. |
| **C.S. Teh** | Co-Founder | Operations & community; prior manufacturing COO; charity founder. |
| **Joezone Joe** | Hardware / IT | 10+ years alarm, CCTV, door access, auto-gate, electrical. |
| **Jack** | Full-stack | Full-stack programmer; end-to-end web systems (front, back, DB). |

**Contact**

- Email: info@pandav.io  
- WhatsApp: +60 18-6622 980  
- X: https://x.com/PandaV_io  
- Telegram: https://t.me/pandav_io  
- YouTube: https://www.youtube.com/@PandaVmy/videos  
- Office: Kuala Lumpur, Malaysia  

---

## 13. Risks and limitations

- **Hardware dependency** — door reliability depends on controller / network path; chain does not replace physical fail-open/fail-closed policies.  
- **Async chain** — NFT transfer can lag after a successful door open; ops tools must cover this.  
- **Regulatory** — access logs and visitor selfies may implicate privacy duties; merchants are data controllers for their venues.  
- **Current single-chain production** — Ergo outage or wallet UX friction can affect issuance and visitor login until additional adapters ship.

---

## 14. Conclusion

PDV is an **access control system**: wallets and Access NFTs become working door keys, backed by merchant SaaS and door hardware (Wiegand / ESP32).

The product is **blockchain-ready** where it helps — ownership, transfer, audit — and remains **practical at the door**. Further features and other chains are an open collaboration surface.

---

*© PandaV Enterprise (TR0300693-M). This document describes the PDV Access Control System only.*