One of the most common questions when getting started with a chastity app is: does a keyholder actually have to track themselves, or even wear a device? The short answer is no. A keyholder controls — they do not wear. To keep that separation as clean in the software as it is in the relationship, the Chastity Tracker consistently distinguishes between three roles. This article explains who does what, why the separation matters, and how to set up a pure keyholder role with no own tracker at all.
Three Roles, Three Jobs
The Chastity Tracker knows three roles. In practice they sometimes overlap, but technically they are cleanly separated.
Wearer
The wearer is the one wearing the device. They record locking, unlocking, inspection and orgasm, manage their own devices, and keep an eye on statistics, goals and the live status. Everything to do with wearing plays out in this area. If you want to understand what such an app does in general, see the overview What Is a Keyholder App.
Keyholder
The keyholder directs and controls. They set lock periods, request inspections, define training goals and rule in the penalty log. Their workspace is the keyholder overview: a sub card per person they manage, that person's status, and the directives issued. The key point: for all of this, the keyholder needs no chastity device and no wear history of their own.
Admin
The admin is the operational role of the instance. They create, edit and delete users and assign roles. This is pure account administration — technical, not content-related. The admin does not decide on lock periods or verdicts, but on who has access at all and in which role. In many setups the keyholder is also the admin, but that is one person holding two roles, not a technical requirement.
Why the Separation Matters at All
Keeping roles cleanly separate is not an end in itself. In a D/s dynamic, the power exchange is the core of the arrangement. If the controlling person lands in the same view where tracking and documentation happen, that very boundary blurs. A clear separation ensures each role only sees and does what belongs to it.
There is also a practical aspect: data clarity. Statistics, goals and wear times always refer to the wearer. A keyholder who produces no entries of their own keeps these analyses clean. There is no confusion about whose wear time is currently being shown.
The Pure Keyholder Role: No Own Tracker
For keyholders who only control, there is the "No own tracker" mode. When it is active, the application hides the personal tracker area entirely. The login then no longer leads into a personal tracking view but straight into the keyholder overview — where the managed people, their status and the directives live.
Two properties of this mode matter. First, no data is deleted. If the account ever had entries, they are preserved and merely hidden. Second, the switch is reversible at any time. Anyone who later does want to wear and track can re-enable their own area with a single click. The role is therefore a setting, not a one-way street.
Separate Areas: Overview and Management
Two areas are often confused in daily use but are deliberately separate: the keyholder overview and user management.
The keyholder overview is the content-related workspace. Here the keyholder sees a sub card per managed person with the current status and the open and completed directives. From here, lock periods are set, automatic inspections and manual inspections are triggered, and verdicts are reached.
User management, by contrast, is purely the instance admin's account administration. It serves to create, edit, delete and assign roles to accounts. Anyone who only controls and wears nothing themselves therefore works in the overview as a pure keyholder, with no own tracker to maintain in management.
Which Constellations This Covers
The three roles plus the "No own tracker" mode cover the common dynamics:
- Classically separated: One person is a pure keyholder without an own tracker, the other is the wearer. After login, the keyholder lands directly in the overview.
- Keyholder with multiple wearers: One keyholder manages several wearers, each cleanly scoped into its own sub card, without tracking themselves.
- Switch dynamic: Anyone who lives both sides keeps their own tracker active and uses the keyholder overview at the same time. The mode simply stays off here.
- Admin in one person: The keyholder administers the instance themselves, controls via the overview, and still wears nothing.
Freely Chosen Landing Page
The "No own tracker" mode also determines where the login lands. For a pure keyholder, the personal tracking view has no content — skipping it and starting directly in the keyholder overview saves a detour on every sign-in. The landing page thus follows the role: those who wear start in the tracker; those who control start in the overview.
Conclusion
A keyholder does not have to track themselves or wear a device. The Chastity Tracker cleanly separates wearer, keyholder and admin, and lets keyholders take on a pure control role with the "No own tracker" mode — without data loss and reversible at any time. This way the software mirrors the relationship instead of forcing it into a rigid scheme: each role sees exactly what belongs to it, and the power exchange stays visibly separate in the interface too.