docs: signer is in-tree - align custody claims after #7/#8 merged
#7 (signer) and #8 (builder hardening) merged into main this morning; this branch is rebased onto the result and packages/signer is now in-tree. Three sites still said pairing the signer with the hosted builder "does not yet remove the custody exposure" (true when #7 was written, before this PR's keyless build_* tools existed - now false for the wallet/tx/contract family): - README.md's "Local signer" section: now states the 4-call non-custodial flow (signer_get_address -> build_* -> signer_sign -> submit -> await) is live today for that family, names the signer's four tools, and keeps the agent-registry/self-improvement families explicitly scoped out. - packages/signer/README.md's "Known limitations" bullet and "Running it" closing line: same correction, with the specific now-keyless build_* tool names and an accurate (not overclaiming) description of what the E2E test exercises - it signs with the same CML primitives sign.ts uses, as a stand-in for calling vector_signer_sign directly, not a call into the signer package's own code. Grepped case-insensitively across the repo for "does not yet remove" / "custody exposure" / "signer half is ready" / "builder half is not yet" before and after: exactly these 3 sites found, all corrected, zero stale instances remain.
This commit is contained in:
23
README.md
23
README.md
@@ -39,15 +39,22 @@ Self-hosting instructions are below.
|
||||
`packages/signer` is a local MCP server that holds your key and signs transactions locally
|
||||
instead of handing your mnemonic to a shared host. It has **no network access at all** —
|
||||
stdio transport, no Provider, no egress — so a key given to it never reaches a shared server
|
||||
or your model provider.
|
||||
or your model provider. Four tools: `vector_signer_get_address`, `vector_signer_decode_transaction`,
|
||||
`vector_signer_sign`, `vector_signer_get_spend_limits`.
|
||||
|
||||
See [`packages/signer/README.md`](packages/signer/README.md) for configuration, its tools, and
|
||||
known limitations — including the gap that matters most right now: the hosted builder's tools
|
||||
above still require your mnemonic as a call parameter, so pairing the signer with *this*
|
||||
hosted builder does not yet remove the custody exposure described above. Closing that gap is
|
||||
the next stage of the migration described in
|
||||
[`docs/architecture/non-custodial-split.md`](docs/architecture/non-custodial-split.md); until
|
||||
it ships, the security notice above still applies.
|
||||
**Paired with this hosted builder, the full non-custodial flow is live today** for the wallet,
|
||||
transaction, and smart-contract family: `vector_signer_get_address` → `build_*` →
|
||||
`vector_signer_sign` → `vector_submit_transaction` → `vector_await_transaction`. No step in that
|
||||
chain puts a mnemonic in front of this server or your model provider. The build → submit → await
|
||||
half is E2E-proven on Vector testnet, landing a real signed transaction on-chain; see
|
||||
[`packages/signer/README.md`](packages/signer/README.md#known-limitations) for exactly what that
|
||||
test does and does not exercise on the signer's side. **The agent-registry and self-improvement
|
||||
families are not part of that pairing yet** — they still take a mnemonic as a tool-call
|
||||
parameter until their own keyless migration lands (see the security notice above and
|
||||
[docs/architecture/non-custodial-split.md](docs/architecture/non-custodial-split.md)).
|
||||
|
||||
See [`packages/signer/README.md`](packages/signer/README.md) for configuration, tools, and known
|
||||
limitations.
|
||||
|
||||
## Features
|
||||
|
||||
|
||||
@@ -144,17 +144,28 @@ over-counts, which refuses too much rather than too little.
|
||||
- **Prompt injection is bounded, not eliminated.** Policy refuses out-of-limit
|
||||
transactions, but an injected agent can still cause any transaction *within* policy.
|
||||
Recipient allowlisting is the next lever.
|
||||
- **Pairing this signer with the hosted builder does not yet remove the custody exposure it
|
||||
is designed to fix.** The signer's own four tools are complete and independently verified
|
||||
end to end against live chain data (`test/integration/roundtrip.test.ts`). What is not yet
|
||||
true is a wired-up keyless round trip through the hosted *builder's* actual tools: today
|
||||
every builder tool that builds or sends a transaction (`vector_send_apex`,
|
||||
`vector_build_transaction`, the registry and governance tools, ...) still requires your
|
||||
mnemonic as a call parameter, and no `submit_transaction` tool exists yet to submit a
|
||||
transaction this signer produced. That migration is tracked separately in
|
||||
- **Pairing this signer with the hosted builder now removes the custody exposure it was
|
||||
designed to fix — for the wallet, transaction, and smart-contract family.** The signer's own
|
||||
four tools are complete and independently verified end to end against live chain data
|
||||
(`test/integration/roundtrip.test.ts`), and the hosted *builder's* tools in that family are
|
||||
keyless: `vector_build_send_apex`, `vector_build_send_tokens`, `vector_build_transaction`,
|
||||
`vector_build_deploy_contract`, and `vector_build_interact_contract` all take a wallet
|
||||
*address*, never a mnemonic, and `vector_submit_transaction` / `vector_await_transaction`
|
||||
complete the round trip. The pipeline — hosted keyless build → sign → submit → await — is
|
||||
E2E-proven on Vector testnet (`packages/builder/test/integration/keyless-e2e.test.ts`): a
|
||||
builder-produced unsigned transaction is signed with the same CML primitives `sign.ts` uses
|
||||
(hash the body, produce a vkey witness, attach it — explicitly a stand-in for calling
|
||||
`vector_signer_sign` directly, not a call to this package's own code), then submitted and
|
||||
confirmed on real Vector testnet blocks. This signer's own tool surface, policy engine, and
|
||||
audit log are exercised separately, by this package's own suite
|
||||
(`test/integration/roundtrip.test.ts` and the smoke tests above). **What is still open: the
|
||||
agent-registry and self-improvement tool families.** Their tools still require your mnemonic
|
||||
as a call
|
||||
parameter, so pairing this signer with the builder does not yet cover them. That migration is
|
||||
tracked separately in
|
||||
[`docs/architecture/non-custodial-split.md`](../../docs/architecture/non-custodial-split.md)
|
||||
(PRs 6-8) and has not shipped. Until it does, the root README's custody notice still
|
||||
describes the hosted builder accurately.
|
||||
and has not shipped. Until it does, the root README's custody notice still describes those two
|
||||
families accurately.
|
||||
|
||||
## Running it
|
||||
|
||||
@@ -180,9 +191,10 @@ example):
|
||||
}
|
||||
```
|
||||
|
||||
Register it alongside the hosted builder so an agent has both sets of tools available. See the
|
||||
last bullet under Known limitations above before expecting that pairing to keep your mnemonic
|
||||
off the hosted server today — the signer half is ready; the builder half is not yet.
|
||||
Register it alongside the hosted builder so an agent has both sets of tools available. For the
|
||||
wallet, transaction, and smart-contract family, this pairing keeps your mnemonic off the hosted
|
||||
server today — both halves are ready. See the last bullet under Known limitations above for
|
||||
what's still open: the agent-registry and self-improvement families.
|
||||
|
||||
## Testing
|
||||
|
||||
|
||||
Reference in New Issue
Block a user