Redemption, verified end to end

The house issues a token that entitles its holder to a piece. On Ethereum that is a contract the house already has, or one we deploy for it. On Bitcoin it is a set of inscriptions the house names. Either way the entitlement is public before anyone redeems it, which is what makes the rest of this possible.

A house that already has a contract keeps it. We read from it and we never need to change it. A house issuing for the first time gets a contract that records who redeemed each token permanently, because that record is what our service relies on.

A collector holds the token in a wallet of their own. We never take custody, there is no account to create, and there is nothing to deposit. The wallet is the identity, and a collector who holds pieces in several wallets is one person to us with several wallets attached.

Signing in is a signature on a message we issue, verified on our side. It costs nothing and moves nothing. On Bitcoin it is a BIP-322 signature from the ordinals address, which is a different key from the payment address in the same wallet. That distinction is easy to get wrong and we built the flow around getting it right.

Before a claim can start we read from the chain whether the wallet holds the token now. We ask the contract on Ethereum and an index on Bitcoin, from our servers, at that moment. What the browser says a wallet holds is never treated as evidence, and the interface only ever offers a collector the tokens their wallet actually holds.

The check is done twice, because starting a claim and finishing it are minutes apart and the second is where the piece is won. Both times the wallet has to be one the collector has proven on their account, and both times it has to hold the token.

The collector chooses what is to be made where there is a choice, sees what is included and what would be quoted, accepts the house’s terms in the house’s own words, and gives a delivery address. Each accepted term is stored as the exact text that was shown, so the house can say later what the collector agreed to.

On Ethereum the redemption is the contract’s own function, and the wallet shows the collector exactly that and nothing else. On Bitcoin the redemption is a signature. We never ask a Bitcoin wallet for a transaction, because an inscription can only be lost by being spent, and a flow with no transaction in it cannot spend one.

The house makes the piece and dispatches it. The collector follows it on the same portal, accepts or declines a quote there if there is one, and is told by the house when something needs them. Declining a quote never affects a redemption; the collector keeps an included option instead.

After delivery the token stays with the collector and the record stays with the piece. If the token is sold later, the piece does not go with it, and the record says who it went to.

On Ethereum, wallets connect through the discovery standard every modern wallet supports, or by QR code from a phone. Sign-in is a signed message. Redemption is the contract’s own function, and the contract names the redeemer for good.

On Bitcoin, wallets connect through the ordinals-native wallets, which expose the ordinals address separately from the payment address. Sign-in and the claim are a BIP-322 signature from a mainnet taproot address, verified on our side. There is no transaction, no PSBT and no transfer anywhere in the flow. Holding is read once from an index and recorded, and the wallet’s own claim about what it holds is never evidence.

As far as we have been able to find, nobody else runs redemption as a service on both chains for a house. Bitcoin redemption has been done as one-off drops. We built it as something a house can commission.

Chain reads happen on our servers, never in the browser. A claim is bound to a proven wallet at the start and again at the finish. A change of address is authorised by one signature for one address, so a stolen session cannot redirect a piece and a signature for one address cannot be replayed for another.

Staff access to the console is resolved from the database on every request rather than carried in a session, so revoking it takes effect on the next click, and there is no screen that grants a role. Audit entries, on-chain redemptions and accepted terms cannot be updated or deleted at the database grant level.

Every page ships with a content security policy carrying a per-request nonce and no inline scripts, and the wallet origins it admits were taken from observed traffic rather than guessed. The database is in London and is never provisioned anywhere else. Mail is sent under a role assumed at request time, so there is no long-lived cloud credential to leak.

The house gives us the contract address, or the list of inscriptions, or tells us it wants to issue. It gives us the catalogue, which is what each token entitles, the options, what is included and what is quoted, and the terms a collector accepts before redeeming, in the house’s own words. It gives us a mark and a palette. The portal is the house’s, and we appear on it as a hallmark.

We provide the portal, on a subdomain of provatek.io in the house’s name, the console for the workshop, the record, and the notices collectors receive on the steps that need them. A house with an existing contract is usually live within weeks, and the first thing we do together is reconcile whatever was redeemed before we arrived.