TXtxpipe
Patterns

Add Pattern (*)

Add a new pattern to watch and force the server to re-sync from a given point. Only blocks discovered from that point will be matched against the new pattern.

This endpoint may not be instantaneous as the forced rollback may only occur after the next block arrives in the indexer. On the main network, this takes usually no more than 20 seconds. On test networks however where the block density tends to be much lower, this may take longer.

Note also that, very long rollback will take a substantial amount of time to be processed by the server; if the server is shut down while a rollback is ongoing, the rollback will be aborted and the server will remain where it was, although with the extra pattern added.

put/patterns/{pattern}

Request

Path parameters

'*' required
OR
OR
string required
  ┏━━━━━━━━━━━┓ ╭───╮ ┏━━━━━━━━━━━━┓
╾─┫ POLICY_ID ┣─┤ . ├─┫ ASSET_NAME ┣─╼
  ┗━━━━━━━━━━━┛ ╰───╯ ┗━━━━━━━━━━━━┛

A policy id (base16-encoded) and an optional asset name (base16-encoded), dot-separated.

Examples:

  • 1220099e5e430475c219518179efc7e6c8289db028904834025d5b086.*
  • 1220099e5e430475c219518179efc7e6c8289db028904834025d5b086.08661220099e
OR
string required
  ┏━━━━━━━━━━━━━━┓ ╭───╮ ┏━━━━━━━━━━━━━━━━┓
╾─┫ OUTPUT_INDEX ┣─┤ @ ├─┫ TRANSACTION_ID ┣─╼
  ┗━━━━━━━━━━━━━━┛ ╰───╯ ┗━━━━━━━━━━━━━━━━┛

An (optional) output index and transaction id (base16-encoded), separated by a @.

Examples:

  • 42@35d8340cd6a5d31bf9d09706b92adedf9b1b632e682fdab9fc8865ee3de14e09
  • *@35d8340cd6a5d31bf9d09706b92adedf9b1b632e682fdab9fc8865ee3de14e09

A matching pattern on addresses, assets or transactions.

See Patterns for more details.

Request body

limit'unsafe_allow_beyond_safe_zone' | 'within_safe_zone'

Specify the server behavior when rolling back out of the safe zone. As mentioned in the user manual, when running Kupo with --prune-utxo enabled, the server gets rid of spent UTxOs, but it only does so after a certain time. That time is exactly 129600 slots (or 36h on Mainnet/Testnet). This is because the core protocol cannot roll back further than this particular depth and it is the point after which it is 100% safe to remove data from the database.

However, this endpoint allows you to break this invariant and rollback to points that are even older in the past. As a consequence, while syncing, the index may be in a somewhat inconsistent state because some inputs spent at a later time may not have been recovered during the rollback. This may be surprising if you're expecting to see and query those transient inputs after rolling back.

By default, you won't be allowed to rollback beyond the safe zone. If, however, you know what you're doing, you're kindly asked to pass unsafe_allow_beyond_safe_zone as a token of acknowledgment. Passing within_safe_zone has no effects other than the default.

Note that, once synchronized again, the index will always be in the expected state and problems reflecting reality only occurs while catching up, after a long rollback.

Example request

{
  "rollback_to": {
    "slot_no": 51540727,
    "header_hash": "9d09...31bf"
  }
}

Response

OK

Changes

No recorded changes to this operation across all 1 revision of this API.