Getting Started: Polar Filament with OpenTag3D

We respect Prusa’s work on OpenPrintTag and share its goal of creating an open RFID ecosystem. We have been in contact with Prusa about RFID standards for roughly a year.

The primary reason we cannot adopt OpenPrintTag is its physical tag and reader requirements.

Prusa’s current implementation uses NFC-V tags and specialized antenna hardware. NFC-V is not backward compatible with the inexpensive, widely available NFC Type 2 tags used by OpenTag3D. Likewise, a reader designed only for Prusa’s NFC-V implementation cannot read ordinary NTAG215 or NTAG216 tags.

The required hardware does not fit our existing spool design, and we have not found a reliable source for the required tags that satisfies our manufacturing and domestic-sourcing requirements.

OpenPrintTag is so custom that even Prusa couldn’t adopt it without redesigning its spool.

This is the immediate showstopper: we cannot manufacture around a tag that does not fit our spools and that we cannot reliably source.

Even if the physical compatibility problem were resolved, we still have concerns about parts of the data-storage format, inefficient use of limited tag space, lookup tables, reserved identifiers, and how portions of the standard are centrally governed. Those concerns are secondary to the hardware problem.

We will continue following OpenPrintTag’s development. If the hardware and adoption barriers are resolved, we would gladly reconsider supporting it.

Bambu Lab tags are proprietary and digitally signed. Bambu printer firmware rejects modified or newly created tags that do not contain a valid Bambu signature.

Third-party manufacturers cannot create genuinely compatible custom tags without Bambu’s private signing key or modified printer firmware.

Technical details are available in the Bambu Research Group RFID Tag Guide.

Why it does not meet our needs

We reviewed TigerTag’s standard offline format and determined that it does not store enough of the information we want to include with our filament. TigerTag and OpenTag3D reflect different design priorities, and we concluded that TigerTag is not the right fit for our implementation.

Decentralization

Although anyone can use TigerTag’s basic format, we do not consider the overall system fully decentralized. Some parts still depend on TigerTag acting as the central coordinator. For example, TigerTag maintains the official list that says which number represents each material or manufacturer. If two companies independently used the same number for different materials, readers could not know which meaning was correct. TigerTag also controls official services such as TigerTag+ signing, certification, and product-ID assignment. In our view, a system is not fully decentralized when one organization must coordinate important identifiers or provide official features, even if the underlying format is free and publicly documented.

Lookup tables

TigerTag uses shared lookup tables for some values. For example, the tag stores a numeric material ID, and software uses a reference table to determine which material that ID represents. TigerTag’s reference tables are public and can be copied and used offline. However, the official meanings and ID assignments are maintained in a central reference registry, and assigning an ID independently risks a collision. OpenTag3D instead stores material definitions directly on the tag, so a manufacturer can introduce a new material value without waiting for a registry assignment. Even when the tables are used offline, interoperability depends on a shared, centrally maintained namespace.

NDEF compatibility

TigerTag stores its payload at fixed locations in raw tag memory. OpenTag3D intentionally uses an NDEF record instead. NDEF adds some overhead, but it has broad tooling and platform support and, where supported, technologies such as Web NFC can access NDEF records from a website without requiring a dedicated native app. We believe that makes OpenTag3D easier to integrate into a wider range of projects.

Optional paid features

TigerTag+ adds optional centrally managed features including official product-ID allocation, signature issuance, certification, and related services. The underlying TigerTag format remains openly implementable and usable offline, but some of these official TigerTag+ features are paid and introduce central dependencies that OpenTag3D is specifically designed to avoid. For our requirements, the base offline TigerTag format does not contain enough of the information we want to store, while some TigerTag+ functionality introduces centralized dependencies we prefer not to adopt.

Open source means a format or its software is publicly documented and available for others to inspect or implement.

Decentralized describes how the ecosystem is governed and whether normal use depends on a central authority or service.

Even with an open license, an RFID ecosystem may still rely on shared coordination for:

• Lookup tables and identifier assignments
• Reserved IDs and data ranges
• Which changes enter the official specification
• Centrally operated services
• Commercial certification or signature programs

These structures can leave portions of an ecosystem dependent on the organization that maintains its registries, services, certification programs, or governance, even when the underlying specification is openly licensed.

Polar Filament prefers designs where both the format and normal ecosystem usage can function without central dependencies. OpenTag3D stores essential printing information directly on the tag in an independently readable form. Reading it does not require an account, internet connection, company-controlled database, or permission from a central authority.

No company, including Polar Filament, owns or controls OpenTag3D. The community governs the project collectively, and the published specification can be forked and maintained independently if any contributor disappears or changes direction. Existing tags remain readable, and development can continue without a company’s permission.