Migrations
Step by step moves between versions, and the general procedure for any upgrade.
Universe implementation Verified 2026-08-31
Describes what a Bitcoin Universe service actually does today. It is not a statement about the protocol in general.
- Page ID
-
releases/migrations - Normative authority
- Universe implementation documentation
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- developer, integrator
- Owner
- bitcoin-universe-docs
- Sources
-
- Universe ARC-20 index and Marketplace v1 authority
at
670030e50071private repository
- Universe ARC-20 index and Marketplace v1 authority
at
此内容尚不支持你的语言。
The general procedure
Section titled “The general procedure”- Record your current pins: validator revision, network, service revisions, schema versions, and documentation version.
- Read the changelog between your pins and the target.
- Read every applicable migration below.
- Re-run the conformance vectors against the target combination.
- Regenerate your client from the target OpenAPI document.
- Diff the generated types. Anything that changed shape is work.
- Test against the target outside production.
- Move, then verify with real reads before switching traffic.
Step four catches interpretation changes that a type diff cannot show.
Migration: legacy buy to reservation and purchase
Section titled “Migration: legacy buy to reservation and purchase”Old behavior. One call created a purchase intent and prepared the transaction together.
New behavior. Two calls. POST /reservations holds the listing and returns the complete
reservation projection. POST /purchases/prepare builds the settlement transaction from that
reservation.
Why. Separating them makes the reservation projection inspectable before anything is prepared, and lets a client reload it without mutation.
Steps.
- Replace the single call with
POST /reservations. - Store the returned
reservationIdand the complete projection. - Call
POST /purchases/preparewith thatreservationId. - Continue with validate-signed and broadcast as before.
- Use one idempotency key per logical action, reused across retries of that action.
Compatibility impact. The legacy alias remains available. Reservation expiry is now visible, so handle an expired reservation by reserving again.
Migration: legacy reconcile to settlement reconcile
Section titled “Migration: legacy reconcile to settlement reconcile”Old behavior. POST /orders/{orderId}/reconcile.
New behavior. POST /settlements/{orderId}/reconcile.
Steps. Change the path. The request and response shapes are unchanged.
Compatibility impact. None beyond the path. Both remain available.
Migration: to the documentation platform
Section titled “Migration: to the documentation platform”Anything linking to the earlier standalone files keeps working. Those routes are generated from the current content on every build.
| If you linked to | It still resolves | The current page is |
|---|---|---|
/specification.html |
Yes | ARC-20 |
/sources.html |
Yes | Versions and compatibility |
/reference.html |
Yes | Reference |
/guide.html |
Yes | Guides |
/llms.txt |
Yes | Unchanged in purpose, expanded in content |
New links should use the page routes. Agents should key on page IDs from the manifest.
Migrating a validator revision
Section titled “Migrating a validator revision”Move one thing at a time.
- Move the validator revision. Re-run the vectors. Verify with real reads.
- Only then move the API revision. Re-run the vectors again.
Moving both at once makes an unexpected difference impossible to attribute.