The protocol

Register & form alliances

Prove you control your domain to get a URSY ID, then exchange Tuckers with a partner to open an alliance. The exchange is visible, and it is the proof.

Worked example · not a live alliance · demo-only values · 10 Tuckers each way
demo-tea.example
would wear
10 × demo-biscuit.example Tucker
⇄
handshake
demo-biscuit.example
would wear
10 × demo-tea.example Tucker

You only hold another entity's Tuckers if it spent its own earned credibility to send them — so the alliance is provable on both records. If it degrades, either side withdraws its Tuckers and it ends.

Static example · not live

What registration will prove

The public page does not issue credentials. It shows the shape of the proof: domain control first, then a signed entity record, then future reciprocal Tucker commitment only when at least two verified entities exist.

01 · Domain proof

Publish a well-known challenge

Example path: https://example.com/.well-known/ursy-node.txt

Example nonce: URSY-DEMO-CHALLENGE-000000

02 · Public entity record

A verified entity receives an ID

Example ID: URSY-DEMO-001. A real private signing key is never printed on a public page and is never shared with another entity.

03 · Future alliance rule

Reciprocal commitment, not directory placement

A live alliance needs 2+ verified entities and visible reciprocal Tucker commitment. Discovery layers, service-domain mesh links and knowledge pairings are not active commerce alliances.

Current live state

teas.co.uk is the first verified entity. URSY currently has zero active alliances and zero minted Tucker tokens.