> ## Documentation Index
> Fetch the complete documentation index at: https://docs.botshield.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Presence Anchors (Deprecated)

> Presence Anchors are deprecated. The durable-trust model is now the Verified Signal plus the Connected Account model.

# Presence Anchors

<Warning>
  **Presence Anchors are deprecated.** The term was retired in the v3 vocabulary (Canonical Definitions v5). The durable-trust mechanism it described is now delivered by the **Verified Signal** plus the **Connected Account** model. There is no `anchor` primitive in the current API. This page exists so older integrations and docs that mention "anchors" can find the current model.
</Warning>

## What replaced it

Earlier drafts described a per-partner "anchor" token that reduced friction for returning users. That design did not ship. Two distinct, already-shipping mechanisms now cover what anchors were meant to do:

* **MultiPass** — the consumer's standing, portable credential. Once a user has verified, their MultiPass keeps them in a `pass` state across BotShield-integrated platforms for the duration of its freshness window, with no re-prompt. This is the actual "returning user, reduced friction" mechanism in production today. See [Signal Durability](/concepts/signal-durability) and [Trusted Account Signal](/concepts/trusted-account-signal).
* **Verified Signal** *(Phase II)* — the durable trust credential that emerges once a user has docked an identity provider, docked an authorized agent, and added at least one Connected Account. It is the installable CAPTCHA replacement: a platform integrates once, a user verifies once, the signal persists (with a TTL). High-impact actions always require fresh presence regardless of Verified Signal state.

Neither model is partner-scoped in the way anchors were described. MultiPass is the consumer's own portable credential; the Verified Signal is a durable trust state at the BotShield layer. In both cases **no identity crosses the partner boundary** — partners see only that a human is verified, never who.

## If you are integrating today

Use [SDK A (BotShield SDK)](/sdk/overview). Every verification produces a fresh, hardware-backed Human Presence Signal. Returning-user friction reduction is already handled for you by MultiPass freshness — you do not create or manage any anchor.

When the Verified Signal SDK (SDK B / Phase II) becomes available, durable-trust acceptance becomes available without any change to the no-PII boundary contract.

## Mapping old terms to current vocabulary

| Deprecated term               | Current model                                                                                                 |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Presence Anchor               | MultiPass (per-user standing credential) + Verified Signal (durable trust state)                              |
| "Anchor with this platform"   | Add to MultiPass (post-verify acquisition surface)                                                            |
| "3 anchors unlock continuity" | Presence Continuity eligibility — see [Presence Continuity](/concepts/presence-continuity) (SDK B / Phase II) |

## Related

* [Presence Continuity](/concepts/presence-continuity) — the Phase II reduced-friction capability
* [Signal Durability](/concepts/signal-durability) — the MultiPass freshness mechanism in production today
* [Trusted Account Signal](/concepts/trusted-account-signal) — how Connected / Trusted Accounts strengthen durability
* [Human Presence](/concepts/human-presence) — core presence concepts and Census result states
* [SDK Overview](/sdk/overview) — current API architecture