Pactus Berlin: What a Live Anchor Preserves

A software release and a separate protocol switch

On October 28, 2026, Pactus released version 1.17.0, named Berlin. Its native state anchoring feature gives an account a place to retain a current commitment to off-chain data. The release and its implementation are available, but PIP-50 makes the feature conditional on protocol version 5. This article examines the published design and released code; it does not independently establish that mainnet has switched to v5.^[1][2][3]

PIP-51 tells a proposer to raise the block version when its view of announced support exceeds 75% of committee power, not 75% of node count. PIP-50 adds a crucial qualification: this is a proposer transition rule, not a block-validity test based on each node’s local support estimate. Those estimates can differ. Nodes accept valid, certified v5 blocks; producing the required certificate needs more than two-thirds of committee power running v5-capable software. A release tag or a support percentage alone is therefore not proof of a completed transition.^[3][4]

A current statement, rather than another receipt

A transaction memo can show that an account recorded a digest in the past. That does not answer whether the account still attests to it. PIP-50 puts one optional anchor in the account’s current state, covered by the existing account Merkle tree and the global state root. A node that has pruned old transaction bodies can still read that live slot.^[3]

The slot holds a bounded hash, an optional location for external data, a type hint, the locked deposit and creation/update fields. It does not hold the document, an application database or a search index. For a service manifest, for example, an application could compare its external document with the account’s current commitment instead of treating an old transaction as proof that the manifest is still current. This is an application pattern described by the PIP, not evidence of a deployed service.^[3]

The deposit belongs to the occupied slot

The detailed rules are more precise than the announcement’s broad wording about create and update deposits. Creating a slot locks at least 1 PAC. For an existing slot, the additional deposit may be 0: the existing lock remains, and the transaction fee still applies. The v1.17.0 executor applies the minimum-deposit check only when no anchor exists. Deleting the slot returns its locked deposit minus the deletion fee. This is a refundable lock on occupied state, not interest, yield or a promise that every operation is free.^[3][5]

A block timestamp is not an independent clock

Creation height and time come from the block that creates the slot; the signer cannot supply arbitrary timestamp fields. The update fields refer to the block that set the current root hash. Changing only the location, type hint or deposit while retaining the same hash does not reset that date. Both PIP-50 and the tagged executor preserve this distinction.^[3][5]

That prevents a transaction author from simply typing a preferred date into the anchor payload. It does not turn the timestamp into a trusted external clock. The Unix time comes from the proposer’s block header and remains subject to the protocol’s accepted timing bounds. PIP-50 identifies block height as the authoritative ordering. A date attached to a digest should therefore be read as a chain observation, not independent proof of an exact real-world moment.^[3]

Deleting an anchor also removes its dates

The useful promise of pruning resistance is narrow: a slot that remains in current state can be read without its original transaction. After deletion, GetAnchor reports no active slot and its timestamp fields are gone. Current state alone cannot distinguish an account that never anchored anything from one that anchored and then deleted. Nor can it say when deletion occurred; that evidence is in the delete transaction, which a pruned node may no longer retain.^[3]

This matters for revocation records. Removing the slot ends the current attestation, but does not leave a durable, dated revocation marker in that slot. The PIP describes a different application pattern for evidence that must survive pruning: retain a slot whose current root commits to a revocation registry. The registry’s meaning and supporting data remain the application’s responsibility.^[3]

A matching hash still leaves questions to answer

Comparing external bytes with the committed digest can establish integrity under the chosen hashing convention. It does not prove that a document’s statements are true, that an address belongs to a named person or that the external file will remain available. The optional location is untrusted input, and consensus does not fetch or interpret it. One commitment can represent many items through an off-chain Merkle tree, but the files and inclusion proofs still travel outside the chain.^[3]

There is also a difference between state commitment and the answer on a screen. PIP-50 does not give GetAnchor a proof against the state root. A client querying someone else’s RPC server or explorer therefore trusts that service’s answer; the method alone does not remove that trust. Berlin’s design is useful because it separates a current account statement from historical receipts. Reading it accurately also means keeping document integrity, identity, time, availability and the source of the query response as separate questions.^[3]