Pulling the multisig state and co-signing flow out of LOBSTR Vault

The valuable surface in a Vault setup is not the key. That is generated on the device, encrypted in local storage, and — as LOBSTR states — never reaches Ultra Stellar's servers. What an integrator can actually work with is the multisig policy Vault writes onto the Stellar ledger and the relay it uses to collect the extra signature. Both are readable without touching anyone's secret. That shapes everything below.

Bottom line: most of a Vault integration is ordinary Stellar protocol work. Horizon gives you the signer set, weights and thresholds of any account; the documented relay accepts a half-signed envelope and returns it with Vault's signature; only the device-side pending queue needs hands-on protocol analysis. We would build the account-state and history reads against Horizon as the backbone, bolt the relay handoff on for the signing step, and reserve traffic analysis for the parts the documented relay does not cover.

What a Vault-protected Stellar account exposes

One row is deliberately missing: the signer's secret key. It is not a reachable surface and we do not present it as one.

Getting at the state and the signing handoff

Stellar protocol over Horizon

The ledger is public. Any account's signer array, threshold tiers, balances and full operation history are queryable from a Horizon instance with no consent step, because none of that is personal data held behind a login — it is protocol state. Durable, well-documented, and the same SDKs (py-stellar-sdk, the JS Stellar SDK) every Stellar wallet already uses. This is the backbone of the work.

The documented co-signing relay

LOBSTR publishes an HTTP relay that wallets use to hand Vault a transaction for its signature: a POST of the envelope XDR, no auth header, with a protection layer that can reject an envelope carrying no valid signature. StellarTerm, StellarX, LOBSTR and Stellarport are listed as already integrated, so the contract is stable and observable. Low effort, high durability.

Authorized protocol analysis of the app traffic

The device-side pending queue and push registration sit outside that documented relay POST. Where a project needs the in-app request feed itself, we analyse the Vault client — its iOS and Android sources are open under the Lobstrco organisation — and the app's own traffic under your authorization. More effort, and it needs a recheck when the client updates, which we account for in maintenance.

For almost every brief, Horizon carries the read side and the relay carries the write side; traffic analysis is only worth it when you need the live device queue rather than the on-ledger result. That is the split we would propose unless the requirement specifically calls for the in-app feed.

Reading the signer set, then posting an envelope

The detection and handoff are short. This is the shape of it, confirmed against the Horizon account object and LOBSTR's integration notes during the brief:

GET https://horizon.stellar.org/accounts/{G_ACCOUNT}
-> {
     "signers": [
       {"key":"G...USERMASTERKEY","weight":1,"type":"ed25519_public_key"},
       {"key":"GA2T6GR7VXXXBETTERSAFETHANSORRYXXXPROTECTEDBYLOBSTRVAULT",
        "weight":1,"type":"ed25519_public_key"}
     ],
     "thresholds": {"low_threshold":1,"med_threshold":2,"high_threshold":2}
   }

# Marker key documented by LOBSTR for Vault detection
VAULT_MARKER = "GA2T6GR7VXXXBETTERSAFETHANSORRYXXXPROTECTEDBYLOBSTRVAULT"
protected = any(s["key"] == VAULT_MARKER for s in acct["signers"])

# Is a built transaction sufficiently signed for a med-threshold op?
got = sum(s["weight"] for s in acct["signers"] if s["key"] in signed_by)
needs_vault = got < acct["thresholds"]["med_threshold"]

# Hand the half-signed envelope to Vault for the remaining signature
POST https://vault.lobstr.co/api/transactions/
body: xdr=<base64 TransactionEnvelope>          # no auth header
# Protection layer may 4xx an envelope with no valid signature.
# Final signed state is then read back from Horizon, not assumed.
      

Note the weight arithmetic: a Vault account is not always 2-of-2. The same code has to be right for a single-signer setup and a complex n-of-m one, which is why the threshold check is explicit rather than a hardcoded count.

What lands in your repo

For this app the deliverable set is concrete:

• An OpenAPI description covering the Horizon reads we use (account, signers, thresholds, balances, the history endpoints) and the relay POST, with the response fields named.
• A protocol and auth-flow report: the relay's unauthenticated POST and its protection-layer responses, the Vault-detection logic, and — where the device queue is in scope — the traffic findings from the open-source client.
• Runnable source for the key paths in Python and Node.js: detect Vault protection, compute whether an envelope clears the relevant threshold, submit the envelope, reconcile final state from Horizon.
• Automated tests against Stellar testnet so the threshold and detection logic is exercised, not just described.
• A normalized account-and-signer schema so a multisig setup looks the same in your system whether it is 2-of-2 or n-of-m.
• Interface documentation plus data-retention notes for the personal-data layer described below.

Public ledger, private key, and the operator's GDPR footprint

Two layers, treated differently. The ledger layer — signers, thresholds, balances, operation history — is open Stellar protocol data and carries no consent or open-banking obligation; there is no AIS or PSD2 regime in play here, because a self-custodied Stellar account is not a payment account under an account-information scheme. The personal-data layer — the relay's device binding, push registration, and support contact — sits with the operator. Per LOBSTR's privacy policy the wallet line is provided by Ultra Stellar OÜ in Estonia, which puts that layer under the GDPR, supervised by the Estonian Data Protection Inspectorate with the national Personal Data Protection Act adding the local derogations. We work authorized, log what we touch, keep consent records where a real account is involved, and sign an NDA when a project needs one. When a build has to exercise a live account rather than testnet, that is done against a consenting account, arranged with you during onboarding.

What we plan around on a Vault build

Four things specific to this app that we handle as part of the work, not items handed back to you:

• The relay POST is documented and unauthenticated, but the device pending-queue and push registration are not in that surface. We map them from the open-source Vault iOS and Android clients and the app's own traffic, and keep a recheck step in maintenance for when LOBSTR ships a new client build, so the queue view does not silently drift.
• The detection marker is a sentinel string, not a usable ed25519 key — an account may instead be co-signed by a genuine custom Vault signer. We match the documented marker and the weight pattern, so detection holds for both styles.
• Horizon choice matters. The Stellar Development Foundation's public Horizon is rate-limited and history-pruned; we design the sync against either that or a dedicated Horizon / captive-core instance depending on how much history you need, and bake that decision into the build.
• Threshold semantics are per-account. We model the weight-versus-threshold maths so a "this transaction is sufficiently signed" answer is correct across single-signer, 2-of-2, and arbitrary n-of-m configurations.

Where teams wire this in

• A Stellar wallet adding multisig support: detect Vault on an imported account and route outgoing transactions through the relay for co-signing.
• An exchange or custodian wanting an audit trail: pull the protected account's full operation history from Horizon into reconciliation, with the signer policy attached to each entry.
• A treasury tool that needs to know, before submitting, whether an envelope will clear the account's thresholds, and to surface what is still pending on the signer device.
• A risk system that flags accounts whose signer is held in a Vault Signer Card versus a software signer, and alerts when the signer set changes on-ledger.

Screens we worked from

The wider Stellar signing and wallet set

Same network, related data shapes — useful when a single integration has to span more than one client:

• LOBSTR Wallet — the consumer XLM and XRP wallet from the same operator; the account Vault protects is often held here.
• Freighter — the Stellar Development Foundation's browser extension, focused on signing and Soroban dApp interaction.
• Solar Wallet — open-source desktop and mobile wallet from SatoshiPay with its own multisig support.
• xBull Wallet — a browser-extension wallet with local key storage and hardware-wallet support.
• Albedo — a lightweight signing-delegation tool for fast transaction approval without per-app key handling.
• Rabet — a browser-extension Stellar wallet for everyday account management and signing.
• StellarTerm — an open-source trading client that already integrates Vault co-signing.
• StellarX — a Stellar DEX front end, also listed among the integrated Vault clients.
• Vibrant — an SDF-associated wallet tied to disbursement and cash-out flows.
• StellarGuard — a web service adding multisig plus two-factor approval to a Stellar account, the closest analogue to Vault's job.

What was checked, and where

This brief was put together from the app's own store description, the Stellar Horizon account-object reference for the exact signer and threshold field names, the Stellar multisig fundamentals, LOBSTR's developer integration material for the marker key and the relay endpoint, and the open-source Vault client repository as the basis for any traffic analysis. The operator and data-regime points come from LOBSTR's privacy policy. Checked May 2026.

Horizon account object · Stellar signatures & multisig · LOBSTR Vault integration support · Lobstrco/Vault-Android source

Compiled by the OpenBanking Studio integration desk — checked 2026-05-18.

Questions integrators ask about Vault

How do you tell from outside that an account is actually protected by LOBSTR Vault?

Read the account from Horizon and look at its signers array. LOBSTR's integration notes publish a marker signer key, GA2T6GR7VXXXBETTERSAFETHANSORRYXXXPROTECTEDBYLOBSTRVAULT, that flags a Vault-protected account. An account can also be co-signed by a real custom Vault signer key rather than the marker, so we match both the documented sentinel and the weight pattern, not just the string.

Is the Vault signer's private key something you can extract or sync?

No. As LOBSTR describes it, the signer key is generated on the device, encrypted in local storage, and never sent to Ultra Stellar's servers. We do not target key material. What we integrate is the public multisig configuration, the on-chain history of the protected account, and the documented co-signing relay.

We run our own Stellar wallet — what does wiring Vault co-signing into our flow involve?

Build the transaction, sign it with the user's key, then POST the envelope XDR to the documented relay so Vault adds the remaining signature; handle the protection-layer response that rejects envelopes carrying no valid signature, then reconcile the final signed state from Horizon. StellarTerm, StellarX, LOBSTR and Stellarport already follow this pattern, so it is well-trodden.

Does using SDF's public Horizon limit how much protected-account history we can pull?

The Stellar Development Foundation's public Horizon is rate-limited and its history is pruned, so deep statement-style history is not always available there. When you need long history we point the sync at a dedicated Horizon or a captive-core instance instead; which one is decided during the build based on how far back you need to read.

A Vault integration is a tightly bounded build — the Horizon reads are open protocol, the relay POST is documented and already proven by several wallets, so the real engineering is the threshold logic, a clean normalized schema, and any device-queue analysis you ask for. Source-code delivery starts at $300, invoiced only after we hand the code over and you have run it; or skip the build and call our hosted endpoints instead, paying per call with nothing upfront. Either path runs on a one-to-two-week cycle. Tell us the app name and what you need from its data, and we arrange access and compliance with you — start at /contact.html.

Mapping rechecked 2026-05-18.