QR Code technology has become a universal tool for bridging physical and digital experiences. Its simplicity, accessibility, and global adoption have made it indispensable across industries. While QR Codes themselves are technically harmless, there have been instances where malicious actors have used QR Codes to direct users to harmful websites or fraudulent services, leading to device infections, phishing attacks, or unauthorized data collection. These incidents underline the need for a secure, transparent framework for any future use of QR Codes in triggering trusted automations.

The WRCode represents this next step: a secure, standardized approach to trusted automation triggers, defined and governed by wrcode.org.

Defining the WRCode

AI instructions in QR codes have been explored before—but OpenGiraffe introduces a novel architecture that redefines their potential. For the first time, real-time participant verification, tamper-proof runtime-verified templates, and a local PII Vault with personal memory, context, and location awareness are combined into a single system.

This invention enables context-aware automation that adapts to the user—without ever transmitting private data unless explicitly consented to. All sensitive signals remain on the device, yet still guide the AI logic locally for a personalized, secure experience.

By solving the trust, privacy, and interoperability gaps of earlier attempts, this architecture marks a foundational step toward a verifiable global standard for privacy-preserving, AI-powered automation.

A WRCode remains fundamentally a standard QR Code based on the ISO/IEC 18004 specification. The underlying QR technology is unchanged.

What differentiates a WRCode is strict adherence to:

• Security and operational guidelines defined by wrcode.org.
  Includes strict standards for automation logic, data handling, and consent management, forming the foundation for a trustworthy ecosystem.

• Tamper-proof automation templates registered and anchored on the Solana blockchain.
  Each template is cryptographically verifiable, with publisher signatures and runtime checks ensuring integrity at every stage.

• A verifiable ecosystem that ensures public trust, issuer accountability, and transparency for customer-facing automations.
  Supplemented by a vetted open-source code library, enabling modular on-premise extensions. This allows secure business logic to run locally — without exposing data — while still delivering a tailored, intelligent user experience.

In summary: while every WRCode is technically a QR Code, only those QR Codes that conform to the WRCode guidelines qualify as WRCode.

The WRCode Security Framework

Access to PII stored within the Vault is strictly denied unless the WRCode automation is verified in real time through an active internet connection. This is essential to validate the tamper-proof zero-knowledge proofs of the software stack, the WRCode issuer, and the device fingerprint anchored on the Solana blockchain. Without this verification, no sensitive automation involving PII can be executed.

In scenarios where users scan standard QR Codes or WRCode automations while offline, the system will operate in a “non-sensitive” mode: QR Codes can still be scanned and analyzed, and informational content can be displayed, but no AI automation instructions from QR Codes will be triggered, and no PII stored in the Vault will be accessed or released.

This approach ensures that WRCode-compliant applications remain fully functional for general QR Code scanning and offer safe, controlled environments for analyzing standard QR Codes without compromising the strict security and privacy guarantees of WRCode automations. Full WRCode functionality, including AI automation execution and access to sensitive data, is only permitted once the system confirms the authenticity of the entire software and identity chain through zero-knowledge proof online verification.

To ensure authenticity and prevent misuse, all Vault applications and WRCode-compliant software must include a mandatory WRCode Validator. This built-in validator checks whether a scanned QR Code conforms to the WRCode standard by verifying its registration, the anchoring of its automation template on the Solana/IOTA blockchain, and the validity of the issuer identity through wrcode.org.

Only QR Codes that successfully pass this validation are permitted to trigger sensitive automations or request access to personal data stored in the Vault. Non-WRCode QR Codes may still be processed by compliant software, such as for analyzing offers or reading non-automated content, but these cases must never access or unlock Vault-stored PII.

This mandatory WRCode validation ensures that users and organizations can independently verify whether a code is a genuine WRCode, providing a consistent layer of trust and security across all implementations.

The WRCode standard is built upon a clearly defined set of security and operational guidelines established by wrcode.org, which together ensure the integrity, trustworthiness, and transparency of all WRCode-based automations. These guidelines include:

1. Mandatory Verifiability: All WRCode automations—whether public-facing or internal—must be verifiable through wrcode.org. For customer-facing WRCode automations, the corresponding automation templates must also be transparently published unless there is a justified reason for confidentiality. In cases where templates remain confidential, their existence must still be provably verifiable through cryptographic anchoring on the IOTA blockchain. Additionally, issuers opting for confidentiality must provide a public statement through wrcode.org explaining the nature of the confidentiality, ensuring that users and stakeholders are aware of the verifiable, yet undisclosed, status of the automation template.

2. Tamper-Proof Automation Templates: Every automation template must be cryptographically hashed and anchored on the IOTA blockchain to guarantee immutability and resistance to tampering.

3. Verified Issuer Identities: Organizations issuing WRCode automations must undergo identity verification conducted through wrcode.org. The verified identity is then cryptographically hashed and anchored on the IOTA blockchain, providing tamper-proof verification of the issuer while safeguarding sensitive identity details. This ensures that only authorized publishers can issue trusted automations and that the authenticity of the issuer can always be validated.

4. Secure Vault Software: Vault applications responsible for handling sensitive data must:

   • Adhere strictly to wrcode.org guidelines.

   • Be published under the GNU Affero General Public License v3 (AGPLv3), the same license used by the OpenGiraffe project.

   • Be cryptographically hashed.

   • Be anchored on the IOTA blockchain to ensure authenticity, traceability, and tamper-proof verification.

The Vault must operate as a standalone, independent application to guarantee that all sensitive actions, including PII handling and automation approvals, occur within an untampered, auditable environment. All whitelisting of WRCode providers and user consent decisions must be made exclusively within this original Vault application, ensuring that no proprietary software can override or simulate user approval.

To prevent unauthorized duplication or misuse, each Vault instance must be cryptographically bound to the device on which it is installed. This is achieved by generating a device-specific hardware fingerprint derived from secure elements such as a Trusted Platform Module (TPM), Secure Enclave, or equivalent. The hardware fingerprint, combined with the Vault software hash, is anchored on the IOTA blockchain to establish a tamper-proof link between the Vault and the device.

At runtime, the Vault must verify its own software integrity and confirm the device’s hardware fingerprint before permitting any sensitive operation or data access. This ensures that even if Vault software is copied or tampered with, PII remains inaccessible without the original, trusted hardware environment.

To maintain frictionless user experiences for trusted services, the Vault must allow users to explicitly approve initial PII access and optionally whitelist specific WRCode providers for streamlined future interactions. This whitelisting remains entirely under user control, with the ability to review, revoke, or modify permissions at any time.

To maintain frictionless user experiences for trusted services, the Vault must allow users to explicitly approve initial PII access and optionally whitelist specific WRCode providers for streamlined future interactions. This whitelisting remains entirely under user control, with the ability to review, revoke, or modify permissions at any time. Access to PII is only granted if:

1. The proprietary software calling the Vault passes integrity checks.

2. The Vault software matches the original, hashed version anchored on IOTA.

3. The user has explicitly granted or whitelisted the specific provider.

Vaults may optionally log user approvals and whitelisting events locally in a tamper-proof way to enhance transparency, user control, or compliance needs. These logs are strictly informational and do not contribute to the core security of the WRCode framework, which is fully enforced through cryptographic proofs, anchored software integrity, and device-bound Vault verification. Proprietary WRCode apps must automatically anchor the hashes of every new software release on IOTA to maintain verifiable software integrity. This ensures that all participants follow the guidelines strictly and that users can trust the process without compromise.

Only Vaults issued by verified WRCode publishers and listed on wrcode.org are considered compliant and safe for use.

Together, these elements establish a comprehensive security model that protects users from fraud, manipulation, and unauthorized data access.

Unregistered automations are strongly discouraged, as they expose users to significant risks, including:

• Use of unverified Vault software that may mishandle or leak sensitive data.

• Execution of altered or insecure automation templates.

• Absence of verifiable issuer identity or template integrity.

Only WRCode-compliant automations—fully registered, verifiable, and tamper-proof—should be trusted for customer-facing or security-sensitive applications.

Consumers and enterprises must:

• Use only Vaults published by verified WRCode issuers listed on wrcode.org.

• Verify automation templates through the public registry before execution.

To maintain openness and flexibility, any organization may issue its own Vault software, provided that the software is fully open-source, published on wrcode.org, auditable, and anchored tamper-proof on IOTA.

Such Vault applications must:

• Be published under an approved open-source license.

• Follow the strict security and privacy guidelines set by wrcode.org.

• Be cryptographically hashed and anchored on IOTA to ensure authenticity, integrity, and verifiability.

This approach allows companies to build their own compliant Vault solutions while maintaining the core trust and security guarantees of the WRCode ecosystem.

This framework prevents fraudulent actors from manipulating automations or distributing unauthorized Vaults.

Future Execution Layer: QRGiraffe

The forthcoming QRGiraffe orchestration environment will leverage the full potential of the OpenGiraffe AI Agent Orchestrator to extend and enhance the capabilities of WRCode-based automations. QRGiraffe will not be required for WRCode adoption but will serve as an example of how to build advanced, AI-driven automation experiences on top of the WRCode standard.

Timestamped, Open Innovation

The WRCode standard has been:

• Publicly documented and cryptographically timestamped using OpenTimestamps on the Bitcoin blockchain.

• Released under an open, community-driven model to ensure transparency and verifiability.

This guarantees the authenticity, originality, and trustworthiness of the WRCode framework.

The Importance of WRCode

Without a secure standard, QR-based automations would remain vulnerable to:

• Tampering and manipulation

• Spoofed automations and phishing

• Lack of issuer accountability

• Privacy breaches

The WRCode standard addresses these risks through:

• Verified, tamper-proof automation triggers

• Transparent validation and accountability

• Strict Vault and privacy safeguards

Conclusion

The WRCode establishes a trusted, transparent, and verifiable global standard for QR-triggered automation:

• Only QR Codes that meet wrcode.org standards are recognized as WRCode.

• All public WRCode automations must be registered, anchored, and publicly verifiable.

• Vault software must be secured, verifiable, and anchored on IOTA.

By following these principles, WRCode empowers organizations and individuals to adopt QR-triggered automation in a manner that is secure, accountable, and privacy-respecting.

Hotel Check-In Using WRCode: Practical Example

Scenario Overview

A guest arrives at a hotel without a prior booking. In the lobby, a digital screen displays a dynamically generated WRCode that includes all relevant booking details, such as room availability, pricing, and optional services. The guest scans the WRCode using their smartphone or another device equipped with a WRCode-compliant Vault.

This touchless process allows the guest to instantly review the booking information directly on their device. With a single secure confirmation in the Vault, the booking, payment, and check-in process is executed automatically. The WRCode ensures that all automations, including PII handling and transaction processing, are completed securely and transparently without the need to interact with hotel staff.

Step 1: Immediate Check-In

• The WRCode triggers a PII consent screen in the Vault.

• The guest approves, and the Vault validates the WRCode through zero-knowledge proof online verification (hash-only lookup on IOTA).

• The guest’s preferences—such as room temperature, pillow type, or loyalty rewards—are preconfigured by the guest using the hotel’s WRCode generator available on the hotel’s website. Through fine-grained slider settings and service choices, the guest creates a personalized WRCode in advance, which is securely stored in the Vault as non-sensitive external data specifically for later use in automated booking and check-in.

Step 2: Arrival & Access

• Upon arrival at the hotel room, the guest uses the same WRCode to unlock the door.

• All preferences are pre-applied without additional steps.

• The Vault ensures that no sensitive data is shared unless validated and approved.

Step 3: Hotel Services and Stay

• The guest can use additional WRCode-enabled services:

  • Order drinks or food by scanning WR Codes in the room or bar, with charges linked to the room or paid directly via a secure Vault-stored payment method.

  • Book spa appointments or restaurant tables by scanning other WR Codes around the hotel.

  • Connect to the OpenGiraffe Orchestrator on a laptop or tablet to access personalized suggestions: upcoming events, late checkout offers, or tailored experiences.

• The AI automation templates embedded in the WRCode are executed automatically to optimize the stay.

• An intelligent OpenGiraffe optimization layer runs in parallel, checking for better options or dynamic recommendations based on the guest’s preferences, unless toggled off.

Step 4: Check-Out

• Check-out is fully automated via WRCode or the orchestrator.

• Guests receive digital invoices, loyalty point updates, and follow-up service offers.

Security and Privacy

• All WRCode automations are executed only after zero-knowledge proof validation using IOTA anchors.

• No sensitive PII is ever shared or processed without full consent.

• Unverified WR Codes are discarded automatically without execution.

• Optional transaction logs for orders or service confirmations are stored securely within the Vault for verifiability but without exposing personal details.

Offline Use

• If scanned offline, a WRCode behaves like a normal QR Code, displaying basic non-sensitive information.

• If a WRCode is detected but cannot be verified immediately, it is securely stored separately from PII until validation is possible. If it fails validation, it is deleted without execution.