Arweave publishes a small file for good today. Autonomi can show you a price; paying for it is not in this wallet yet. Autonomi uses ANT on Arbitrum, plus ETH network fees; Arweave uses AR.
the last read failed, so this figure may be out of date
what would you like to do?
looking is keyless. anything that sends or signs waits for its own button.
see what i havepay or get paidadd moneybPay once · store a filemy key and my safesee how it worksshow me everything
💸💳📡🗝🗺∞
Accounts & coinssend some, get paid, buy RAM with Abring money in, two waysbPay once · store a fileyour keys live in this tabevery bill and every step, out in the openeverything at once
type your .b name to see your coins. new here? make your name, it takes two minutes.your soul is your .b name or Vaulta account; a new one is a bzDiD, born in the held-hand ceremony
connected as …. not you? the rails bar carries this name and its short 0x fingerprint, an identifier and never a key
type your .b name and press connect to see your coins.
🗝 the keychain: your bzDiD holds every key
Automatic, once your name is connected: your first tap or keypress on this page connects the
keychain by itself, except inside the vault, your accounts, storage, bPay, the sign sheets and the keychain's own buttons, and moving between its parts does not count (the WebAuthn ceremony needs one touch of yours: browsers' law, not ours).
The PRF ceremony re-derives your masterPRK in this tab's memory (never stored, never
sent). From it we derive: the ed25519 soul record key (context bnr.b, same as
onboarding), the Vaulta K1 signing key (context vaulta:yourname), your 0x/EVM
and nostr npub rails (your two addresses), and as many
more as you forge below. Gold path is connect keychain / create passkey / derive: never paste a secret.
A recovery phrase paste stays under scaffold · recovery for import only (same soul, same keys).
1 masterPRK
2 soul · ed25519
3 vaulta · K1
4 eth · next
5 chain authority
📷 sign in with your phone
🛡 your devices
these devices keep your soul under their own passkey. removing one stops it syncing, though a copy it already holds still opens offline.every device that permanently holds this soul, as a seal under its own
passkey; the registry is a soul-signed nostr event (kind 30078) any device can read, extend, revoke.
Revoke de-syncs a device (its cached seal keeps working offline: honest limit; a full kill is the recovery-rotate
lane). Sessions via the QR bridge never enter this list.
loading your devices…
Which devices and keys can make your bzDiD: the full compatibility check
your passkey needs to live in your device's own keychain, like Windows Hello, your Chrome profile, Google or iCloud. if you already have a bzDiD, open it with your passkey instead of making a new one, because a new passkey is a new soul. The passkey must live in a PRF-capable authenticator:
platform ones (Windows Hello, the Chrome profile, Google Password Manager, iCloud Keychain) work;
most third-party managers (Bitwarden, 1Password & friends) don't yet. Create never takes a
manager's word for it: after the "confirmed" the wallet immediately re-touches the exact
passkey just made and demands a real PRF secret from it: if it can't, you're told plainly and
that dead passkey should be deleted (Chrome: ⋮ → Passwords and autofill → Passkeys). A software
passkey confirming instantly is fine; PRF is proven by the touch, not the speed. Hardware keys
must be FIDO2.1-class with a PIN set and room for a resident credential. Older U2F keys won't
be offered. If Windows said "unrecognized" when you inserted your key, use the dedicated
🔑 make a new bzDiD on a hardware key button: it routes through the browser's native USB lane
(no Windows passkey picker at all), which is the fix for exactly that error. Cross-device (the phone-camera QR) works only when the phone's provider has
PRF: on the phone set the default passkey provider to Google/iCloud, or simply open this wallet
on the phone itself. After a successful create, this wallet re-touches that same passkey
automatically: no "which passkey?" picker ever again.
Passkeys are origin-bound: one made at another site (an Anchor/wallet passkey for your
account, say) can never connect here: it signs at its own site only. Your account's existing
key still bridges you in via the bridge scaffold (not the New-bee primary path).
Already hold a bzDiD elsewhere? Don't create a second. Prefer connecting the existing
passkey; recovery-phrase import lives under scaffold · recovery (a new passkey = a new soul).
bring your soul back with your recovery words · scaffold · recovery
type the 24 recovery words you wrote down, and your soul opens here as it was. Import: a 24-word BIP-39 phrase or a bdidrec1… code restores an existing soul (same soul, same keys); the gold path never pastes a secret.
your keychain opens with one touch of your passkey.
your soul's six words · SOUL FINGERPRINT (ed25519 record · bnr.b)
—
—
your signing key for your account · VAULTA K1 SIGNING KEY (vaulta:…)
—
chain authority: checking your account…
🔐 the vault: one keypass, every secret
Bringing keys you already hold: formats, and how they get sealed
The keys you already hold are sealed under one keypass, so you never handle them again,
and every phrase is checked before it goes in. This is everyday storage, so keep big balances on a signing device.
Gold path is connect / inject / derive / passkey; paste is scaffold · recovery only.
The keys you already hold, seed phrases from any wallet
(12 · 15 · 18 · 21 · 24 words) and Vaulta ACTIVE private keys
(5K… · L… · K… · PVT_K1_…), are sealed under a single keypass so you never handle
them raw again. Sealed with PBKDF2-SHA-256 ×600 000 → AES-256-GCM, header
authenticated, salt and IV fresh on every write. Only the ciphertext is stored; it is safe
to back up anywhere. Every phrase is checksum-verified before it goes in: a mistyped
word is caught now, not on the day you need it.
Stated honestly: this is hot storage. It ends the
plaintext juggling; it does not turn a browser key into a cold one, and it cannot protect you
from a page that has been tampered with. For balances you would not accept losing, the answer
is still a signing device.
Choosing your keypass: the one decision to take slowly
Choose your keypass.
It is the only thing between anyone with this browser and every secret inside, so let the wallet
generate one and write it on paper. There is no reset:
if the keypass is lost, nothing can open this vault again.
Eight words from the BIP-39 list is 88 bits of real entropy, which no one
is brute-forcing; without the keypass the vault is unrecoverable by design.
write your keypass on paper before you create the vault, because if it is lost nothing can open this vault again.
openlocks itself after five quiet minutes auto-locks after 5 minutes idle
Gold path for secrets: connect / inject / derive / passkey — not paste.
Sealing a pasted seed or key is scaffold · recovery only (capability kept; never required for New-bee).
bring in the recovery words or key of a wallet you already have
Paste it and the wallet tells what it is and checks it before anything is sealed.
Put a secret in: scaffold · recovery
(optional; the gold path does not paste secrets). The phrase is checksum-verified, the key is
checksum-verified and curve-checked, before anything is sealed. Seed phrase and Vaulta active key
paste are scaffold · recovery; Arweave JWK paste is scaffold · advanced. Prefer inject/connect on each rail.
paste the words or key in the box and the wallet checks it for you.
What is inside.
Secrets stay hidden until you press reveal. 0 secrets
Ways in.
Each keypass and passkey here opens the vault on this browser, and none of them can read another.
The vault itself lives only in this browser, so to open it on another device, save it as a file and
import that file there with your keypass. The slot model: one random
vault master key, wrapped once per keypass (PBKDF2) or passkey (PRF, HKDF), like LUKS keyslots. The slots live in
this browser's copy (localStorage bnr_vault) and in each file exported from it; nothing syncs them, and a file
imports through a keypass slot only.
Evidence class follows T3 §6b — a credential is ranked by where its private key
actually lives, not by brand. E3 = device-bound in a hardware keystore (Windows
Hello, Apple/Google platform passkey on its own hardware, Bitwarden device-bound mobile).
E2 = synced or software-held (iCloud Keychain / Google Password Manager / Bitwarden
vault / a keypass in any manager) — only as strong as that vault account’s own auth.
This page requests no attestation statement, so slots sit at the E2 floor unless you
tell it the authenticator is device-bound.
Your recovery words.
Seal the recovery words of the keychain you are connected with, and your keypass opens them here
whenever you need to restore your bzDiD. They live in this browser, so export sealed vault keeps a copy
that opens anywhere with your keypass. The words sealed are the ones of the soul this
keychain holds in this tab (deriveIdentity over its masterPRK), never a fresh passkey ceremony, which on a
sealed device or with a second passkey for this site could open a different soul. The DID persists; keys
rotate under it.
getting your vault ready.
♾ the key forge: near infinite keys, one soul
How each context gets its own key: derivation, on demand
Every address here comes from your keys. Each context name derives its own key
from your masterPRK: vaulta: for Vaulta account keys, evm: for 0x addresses, then
sol:, btc:, ln: and nostr:; a name the wallet has no coin for is refused.
hive: shows the public Hive account its active key named (same rail as balances).
ar: is your Arweave address, a secp256k1 key under ar:<your name> (Arweave 2.9+);
an RSA key never derives from masterPRK, and an address bound by hand or by an extension is
only followed, never shown as yours.
pq:ml-dsa-65 and pq:ml-kem-768 are your post-quantum public cards
(FIPS 204 signatures; ML-KEM-768 + X25519 "X-Wing" so people can seal things to you),
derived from the same masterPRK your recovery words carry, so those words restore them
too. The signing card shows your self-certifying bzpq1 id; tap either card to
copy your full public card (id, both keys, signature). The secret halves exist only while
the keychain is connected and are wiped when it locks.
Derivation is instant, free, deterministic: the same context always yields the same key on
every device. We persist only the context list (this browser), never a key; keys exist
only while your keychain is connected. Tap a key to copy it.
your addresses come from your keys, and none is ever stored. the forge is unlimited; contexts are names, keys derive on demand
🔒 only me: seal files only you, or people you pick, can open
seal a file with your recovery words. any phone opens it again with the same words, and no one else can.
bpq1 sealed object · AES-256-GCM segments under a random key per file · your own slot: HKDF of the phrase root vault (ruling R2), no public-key step · a slot per person you pick: X-Wing (ML-KEM-768 + X25519), naming no one · the sealer's ML-DSA-65 signature sits inside the encryption · SPEC-BPQ-1
Sealing happens here, in this tab, before the file goes anywhere. Each file gets its
own random 256-bit key (AES-256-GCM). That key is locked once per reader: for you, under a key
your recovery words derive, with no public-key step at all; for each person you pick, under the
X-Wing key (ML-KEM-768 + X25519) in the PQ card they gave you. The sealed file names no reader.
A file you share carries your signature inside it, so only its readers learn it came from you;
a file only for you carries none. Keep it anywhere, publish it, store it
on Autonomi or Arweave: without a reader's words it opens for no one. To revoke, seal a new copy
for new readers; someone who already opened a file keeps what they read. The binding button signs
your classical addresses with your post-quantum id, co-signed by your bzDiD key, so you can prove
later, even after a quantum break, which accounts were yours. Signing a file gives it a detached
post-quantum signature (file.bpqsig.json) that anyone can check here, with no keys.
Spec: SPEC-BPQ-1.
Used the QR bridge before 4 October 2026? That older bridge sent your recovery
root over public relays under a classical key exchange only, so someone who recorded it could open it
once quantum computers arrive, and with it every key that root derives, post-quantum ones included.
Make new recovery words, then, still connected with your old words, bind your new
words: paste the new bzpq1 id into the binding field and bind, and the old id vouches for the new
one while its keys still hold.
⚡ balances: Accounts & coins
⚡ Accounts & coins
Accounts & following
Bring your other accounts together, or follow any public address. No key or wallet connection needed.
Save up to 50 public addresses with labels in this browser. Reading shares the address with public chain services. “My accounts” is your label, not proof of ownership. bPay still uses its connected signing wallet.
Vaulta and Hive accounts work here too. see which chains this wallet can read on every rail. The network picker shows the full wallet scope; entries awaiting a reader are marked not readable here yet.
My accounts
Following
press refresh to check followed balances again; this page sends no alerts. Followed balances stay in their own list. Explorer links show transaction history in a new tab.
your own coins, read from your name and your keychain
Balances come from public chain services. These services receive the public addresses you read.
🌉 let this wallet sign for your account · the bridge: one time, then never manual again
this adds this wallet’s own key to your account beside the keys already there. nothing is removed, and the key you paste is wiped from the page right after the press.
updateauth on the account’s active permission: your bzDiD-derived K1 key joins every key already there, nothing removed, the threshold unchanged. the one-paste lane (add this wallet) adds the K1 key only and signs once with the pasted key. scaffold · recovery can also enroll an account passkey (PUB_WA), which joins the account, though this page does not sign with it yet. either way the pasted key lives in tab memory for that one signature, and both paste fields are cleared on the press.
scaffold · recovery (cypherpunk)
labs and migration: paste the account’s existing active private key here to bridge your derived bzDiD by hand. bee and raver use the one-paste lane instead (add this wallet).
connect or derive first; paste in scaffold · recovery only when recovering
🏭 the account forge: make a new Vaulta account (born from your bzDiD)
how a new account is made: your keychain signs it, and holds its keys
your keychain signs the new account into being and holds its keys. nothing is written down, and it costs its room on the chain, paid from your A.
your bridged account signs newaccount; the new account's owner and
active keys derive from your bzDiD (contexts vaulta:name/owner and
vaulta:name/active). no key is exported, written down, or imported, ever.
Vaulta economics: broadcasting draws on staked CPU/NET, not liquid
(a 0.0000 liquid balance does not block transactions); the RAM purchase draws from liquid A
at core.vaulta, priced live from the rammarket. every account born this way signs with your keychain.
receive needs nothing: your addresses are yours to hand out. send signs with your own keychain,
like every part of this wallet. swap uses the chain's own market. send signs with your bzDiD keys exactly like every lane here; swap rides the RAM market of core.vaulta.
a daily cap, if you want one: spend cap · optional, owner's tool; per unit, never price-converted; the ledger lives in this browser and starts fresh at local midnightno daily cap is set.
every address here comes from your own keychain, and a fresh one for any coin
can be made in the key forge. One soul, every rail: each address here falls out of the
same masterPRK by context tag (Vaulta, one 0x address serving both EVM rails, Solana, Bitcoin L1). Lightning and nostr derive keys,
not payment addresses, so neither is offered as one. There is no second seed and no "connect a wallet" step for these rails;
Hive alone takes one pasted active key, sealed under the keychain. Contexts: evm:name, sol:name, btc:name. QRs are drawn
locally and nothing leaves this page. Where a rail cannot be derived honestly the card says so and shows no address:
a wrong receive address is the one mistake that cannot be undone.
this sends from your own Base and Arbitrum address, so add coins to it from 📥 receive first.
one press reads the fee, signs and sends; the fee is said while it goes out. The address is the derived evm:<soul> keypair, not the Vaulta account. ETH moves native (21000 gas); USDC and ANT move through their token contracts (eth_estimateGas plus 20%). Chain ids 8453 and 42161 are signed into every transaction (EIP-155). The signed bytes and their hash are kept before broadcast, so a lost answer, "already known" or "nonce too low" resends the identical bytes and never signs a second nonce.
paste a Lightning invoice to see what it asks for. this wallet cannot pay it yet. read offline in this tab: no node, no lookup.
Both standards, one door: the prefix decides which is read, and
the read is offline — no node, no lookup, nobody told what you are about to pay. Your
spend cap runs on the decoded amount in sats before anything could be sent. Honest limit,
stated because it is one: paying from this page is not wired — the estate's LN seam pays through
an NWC connection whose budget lives at the hub, and its live leg is parked at a relay ACL
(tools/ln-rail/README.md). A BOLT-12 offer priced in a fiat currency has no satoshi price
until its invoice comes back, so a sats cap refuses it here rather than pretending to check it.
a payment name lets people pay you as you@yourdomain. it needs a domain of your own. your silent-payment address derives from your soul; the record is built here, in this tab.
Self-hosted by construction. A payment name is a
DNS TXT record on a domain you already own — no service, no account, nothing to depend on.
This builds the exact record; you publish it. The offer must be minted by your own node
(the estate's LDK / Alby-Hub per RAIL-FORMULARY-1) — this page will not mint one for you and will
not put a third party's offer under your name. Honest limit: this page holds your
silent-payment address but does not scan for payments to it — BIP-352 scanning walks every
transaction and wants an indexer. Your keys stay reproducible from the two contexts printed on the
card, so any BIP-352 wallet holding this soul can scan and spend. Nothing is stranded; it is simply
not watched from here.
type a name like name@domain and press look up. a public directory sees the name you look up. DNS-over-HTTPS (cloudflare-dns.com) sees the query; its AD flag is trusted as the resolver's word.
Resolution is the one leg that cannot be first-party in a
browser: a page cannot validate a DNSSEC chain without shipping a validating resolver. So this asks
a DNS-over-HTTPS resolver and reports whether that resolver says the answer was
authenticated. Trusting that flag is trusting the resolver — and the resolver sees which name
you looked up. An unauthenticated answer is shown as such and must not be paid on. The
sovereign path is the estate's own validating resolver.
reading today's RAM price…
swap buys RAM for your Vaulta account with A, or sells RAM you own back for A,
on the chain's own market. A Bancor-shaped RAM curve (the bmesh-ram receipts measured it), core.vaulta buyrambytes / sellram, 0.5% fee each way.
pick receive, send or swap to begin.
🧾 Autonomi · ANT storage quote
your other balances are in accounts & coins. Saved public addresses do not grant spending access.
how this price is made: Autonomi prices your exact file, and nothing is paid here
the sharing choice is yours and comes before any price. with 🌐 public chosen, this
browser splits your file into chunks itself and asks Autonomi storage nodes for a price using only
addresses and sizes; the file itself stays in this browser. no hidden default is turned into a
choice, and 🔒 private ways stay visibly unavailable until they are ready. the register (new bee /
raver / cypherpunk) only changes what you can inspect, never who can open the file or what you may
do. nothing is paid or stored here: the price is read and the payment request is cancelled. no ANT
figure is typed by anyone; every figure is a network quote, and what is owed is derived from
the quotes, never asserted (INVOICE-1). network gas (ETH on Arbitrum) is a separate cost. when
paying is earned, only your own button press crosses the waiting state; no chat text, no terminal
and no agent receipt substitutes for it.
loading the Autonomi price panel.
🎟 the voucher: prepay compute, metered fair
🎟 prepay for compute
Prepay for compute work (models, vRAM, whatever the estate meters)
and watch every last drop of it itemized here. Top up from either chain, spend at metered
rates, and the estate's 10% tithe is always visible, never buried.
Two rails in, one A balance, receipts with the tithe line: the same
hash-chained ledger the till meters with, rendered live from the estate oracle
(skaists.buzz). Refusals read as sentences, not codes.
voucher_escrow semantics, live: balances DERIVED from a
hash-chained append-only event log (never stored), refuse-before-write enforced at the
engine, memo-native binding on the A rail (memo = meter key, no binding table), binding
table on the USDC rail, every deposit cites its tx. This panel is a read-only view over
that ledger via the estate oracle; the box owns the writes.
type the meter key you were given to see your prepaid compute balance.
0.0000A—
top up your voucher straight from this wallet; the memo is filled in for you.
A · Vaulta · gasless
send any amount of A to:
—
with this exact memo (the memo is the binding:no memo, no credit, money lost):
—
USDC · Base · tiny gas
send USDC (Base) to:
—
credited at — A per USDC (rate cited below)
rate: —
no memo needed on this rail: your bound address credits you
credited only from the address bound to this meter key on the box (meter.py bind); this wallet cannot see or make that binding, and USDC from any other address is not credited.
spent total: 0.0000 Atopped up: 0.0000 Atithe in there: 0.0000 A(the estate's 10%, shown never buried)
itemized: every receipt, every line
—
🧾 the receipts: every bill recomputed here
How this panel checks every bill: recomputed here, never trusted
the voucher panel reads your balance live from the estate oracle; this panel
reads the estate's public spend-receipt record (SPEC-SPEND-RECEIPT-1, the same shape the b-meter
writes) and recomputes every bill in-page: price × burned = owed, summed from the line items,
never from a stored total. each receipt's verdict is drawn as a comb cell:
PENDING_ANCHOR = honey · PASSED = capped, sealed ⬡ · FAILED = the flag hue #c07f1c
(the validated failure colour, never a new red) · INCONCLUSIVE = nectar. verification carries
no keys: content hash, exact arithmetic and the forward-only chain are checked from the public
record alone. private receipts never appear here. visibility is storage law (§3a): only rows marked
public live in a public store. paste any receipt and the same auditor checks yours.
💳 fund: buy USDC, land it on an address you hold
💳 buy USDC with a card, not open yet
this is a separate card route and it is not wired to bPay yet: bPay cannot spend what it buys.
how the card checkout works: who holds what at each step
The one lane this wallet cannot forge itself: licensed fiat. The buy runs on
Meld's hosted checkout: it opens in its own tab; this page only builds the link.
No server of ours: no BNR endpoint sits in this lane; this wallet signs nothing and
stores nothing. Your address rides in the checkout URL (the fiat rail's law) and Meld sees
what any checkout sees. The key this page carries is public
(a publishable Checkout key): a secret key never touches a page, by Meld's law and ours.
Names welcome: type a .eth name (Basename or ENS-style) and the button resolves
it to its raw 0x address on Base's own resolver before anything launches, by a keyless
read from your browser to public Base RPCs picked at random per lookup, so no single
operator profiles who funds what. Honest limit: whichever provider you land on can see
the lookup: your IP plus the name you asked about. Pasting a raw 0x address skips
resolution entirely. If you'd rather not be seen asking, that is a real choice.
funding not configured: card checkout is not switched on here yet, so there is no buy button to press. it switches on when this site sets its public checkout key.
the fiat funnel’s role: the estate sells, it never operates
the estate is a seller, not an operator: its Base address is a bare
to on Peer's live escrow (EscrowV2 + OrchestratorV3 on Base). it signs nothing, grants
no allowance, runs no relayer. a customer's fiat (Venmo & co.) settles as USDC straight
into it. the estate is never the LP: a third party holds the USDC and takes the fiat;
if the estate played LP its own USDC would just come home (a fiat receipt, not new money).
the 10% tithe rides the customer's intent itself as one referralFees entry, paid
inside Peer's settlement before the balance lands, no second transaction; when no referral
was attached, the split still happens as ONE estate-side exact-multi instruction (seller +
tithe in a single payment: the fallback, SPEC §receive). settlement finality is one vendor
signature until the estate's own witness set exists, priced as such, never hidden.
this shows payments people made to the estate, not money for you. to get money into your wallet, use receive.
the estate's receive address (bare to), not yours:0x89881F83A8C9CE06E34cbDD50A612909a784d7C6
the receive call is keyless: USDC Transfer logs from the orchestrator, public Base RPC picked at random. the page only reads.
the intent shape: tithe attached at signal time
the customer's signalIntent carries the split itself (≤10 referral
recipients, ≤50%, paid from the release before the net lands: ReferralFeeLib, read at source):
to: 0x89881F83…d7C6 ← the estate, bare recipient
referralFees: [ { recipient: 0x8fD7252A29FB759755E30A15E966932EaAD91b75,
basisPoints: 1000 } ] ← the 10% law, one entry
the recipient is the founder-filed tithe address (docs/dispatches/tithe-address.txt).
📡 Arweave: publish a file for good
how publishing works: your own key signs, and this page sends the file to Arweave
your Arweave address is made from your own keychain, and your own key signs what
you publish. this page builds the transaction from the public key only and sends it to a public
Arweave gateway picked at random each time, so nothing passes through a middleman.
Another adapter on the wallet shell, with balance, receive address, send, and one more capability:
PUBLISH. Lanes, in order: the secp256k1 key derived under ar:<soul> (Arweave 2.9+, empty owner,
65-byte recoverable signature); an injected window.arweaveWallet (Wander / arweave.app style) only
as a quiet last resort, where the extension holds the RSA key and signs a format-2 tx this page
built from the public key; a vault-sealed RSA JWK as a labs scaffold. Agents never see private keys.
No bundler, no Turbo, no third-party UI (founder ruling).
published files are public and stay on Arweave for good; they cannot be deleted. files up to 30 KB for now. Larger files need the chunked upload lane, which is not built yet (a 30,000-byte cap here).
Or publish the estate's pinned reference anchor:
checking your Arweave address.
advanced · vault JWK scaffold (optional, not required for New-bee)
Labs / offline only: seal an Arweave JWK in
the vault. Your own keys come first; an extension or a sealed JWK is only a last resort. Never paste a private JWK unless you mean to. RSA is never invented from masterPRK.
✍ composer: the BNR contract surface, no Unicove
✍ write an action and see it before you sign
What you see before anything is signed
you see every part of an action in words before anything is signed, and nothing is called sent until the chain shows it. every action is prepared, signed, kept, sent and then read back from the chain. Give it contract + action and it fetches the live ABI, renders
one field per argument, and shows you exactly what you will sign (action, authorization,
parsed args, signer, endpoint) before anything broadcasts. ABI-driven: the six bnames actions
and anything after work the same way. Mainnet signs with your bridged bzDiD key, zero paste;
the Jungle4 lane rehearses with a test key you paste (TESTNET-ONLY, memory-only). The Unicove
dependency is dead. This is ours, on the adapter contract: the worker builds, the vault signs,
the outbox persists, and nothing is called "sent" until the rail is read back. Mainnet signs with this wallet's derived K1 key only. An account passkey (PUB_WA) that the bridge may add to the account is not a signing lane on this page yet: the vendored eosjs WebAuthnSignatureProvider is unwired and untested.
the receipt ladder: every state is a first-class visual · the order is law
1
BUILDdone
the live ABI renders one field per argument. you see exactly what you will sign: action, authorization, parsed args, signer, endpoint.
2
SIGNdone
your derived bzDiD key signs in tab memory: zero paste. the signature is yours, the bytes are final.
3
PERSISTdone
the signed bytes land in the outbox BEFORE any network. persistence precedes submission: the order is law.
…
SUBMITSUBMITTED: awaiting read-back, not done
the stored bytes broadcast to the rail. a retry resubmits the identical bytes. it never re-signs, never rebuilds. submitted is NOT done.
✓
CONFIRMCONFIRMED: read back from the rail
a block read says so, or nothing does. the receipt names what was read. only the read-back earns the terminal look.
scaffold · Jungle4 test key (TESTNET-ONLY — gold mainnet never pastes)
📤 outbox: signed bytes persist here before they submit
📤 waiting to be sent
The order is law: build → sign → persist → submit → confirm by reading the
rail. A retry resubmits the identical stored bytes. It never re-signs, never rebuilds.
Nothing shows "sent" until a block read says so; the receipt names what was read.
🗺 chain matrix: which networks this wallet can read
Every rail, one row each: how it is read and signed
The original wallet scope plus the Graphene and Cosmos studies, with separate read and sign capabilities. READ means this page has a public account reader; CODE means another implementation exists; EVALUATION means a bounded bench; GAP means required integration is missing; STUDY means researched scope. These labels do not certify a device, a payment or a deployment. Tokens, payment protocols and storage networks are identified separately from blockchains.
PR #338 records 111 receiver-verified x0x deliveries, private-validator Solana proof verification and settlement, and private-chain Vaulta PLONK fixture settlement. Reconciliation remains partial because the separate fixture fee was unpaid. These are private-network results; this wallet does not offer them as public settlement.