Add experimental GenLayer wallet object and agent protocol - #20
acastellana wants to merge 1 commit into
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 564854f7a5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| import { Vault } from './vault.mjs'; | ||
| import schema from './schema.json' with { type: 'json' }; | ||
|
|
||
| const canonical = value => JSON.stringify(value, (_,v)=> typeof v === 'bigint' ? v.toString() : v); |
There was a problem hiding this comment.
Sort object keys before computing idempotency digests
JSON object property order is semantically irrelevant, but canonical preserves insertion order. A retry of the same multi-field prepare request with its args keys serialized in a different order therefore produces a different input string and raises idempotency_conflict, contrary to the protocol's guarantee that the same parameters can reuse a request ID. Recursively sort object keys before hashing or comparing request/config data.
Useful? React with 👍 / 👎.
| if(r.kind!=='native' && simulation.data && simulation.data!=='0x') decoded=decodeFunctionResult({abi:r.abi,functionName:r.function,data:simulation.data}); | ||
| const preview={simulation_result:decoded??null,estimated_gas:estimatedGas.toString(),max_gas_cost_base_units:maxGasCost.toString(),native_value_base_units:value.toString(),recipe:message.recipe,arguments:message.args||{}}; | ||
| const proposal=randomBytes(16).toString('hex'); | ||
| this.db.prepare("INSERT INTO proposals(id,identity,request,input,policy,expires,state,tx,summary) VALUES(?,?,?,?,?,?,'prepared',?,?)").run(proposal,identity,message.request_id,input,this.policy(),Date.now()+this.config.ttl_seconds*1000,canonical(tx),canonical(preview)); |
There was a problem hiding this comment.
Resolve concurrent idempotent inserts to the existing proposal
When two retries for the same sender and request_id overlap, both can miss the lookup on lines 93–94 because the worker starts each core.handle call concurrently (worker.mjs:30-32). The first insert succeeds, while this second insert violates UNIQUE(identity,request) and is returned as operation_failed rather than the same prepared_id. Catch that specific uniqueness conflict and reload/compare the winning row, or serialize the lookup-and-insert transaction.
Useful? React with 👍 / 👎.
| })} | ||
| end) | ||
|
|
||
| {:multi, messages, %{state | ready: false, pending: %{}}} |
There was a problem hiding this comment.
Cache runtime-loss completions before clearing pending requests
If the Node runtime exits while requests are pending and a routed runtime_lost message is missed, this branch clears every pending entry without adding the generated errors to state.results or state.order. A subsequent sender-scoped result request consequently returns unknown_or_pending_request, defeating the documented process-local recovery cache precisely for runtime failures. Store each generated completion in the bounded cache before returning the cleared state.
Useful? React with 👍 / 👎.
Adds an experimental GenLayer testnet object so agents can discover their own wallet and submit permitted EVM actions through a sender-bound prepare/submit/status protocol. Wallet bindings and transaction identities survive restarts; uncertain broadcasts cannot silently become duplicate payments.
The package includes a generated agent skill, native Elixir handler, bundled Node 24 runtime, encrypted key storage, SQLite journal, operator setup command and explicit host recipe configuration. It supports intelligent-contract reads; intelligent writes and verified GenSwap buy/sell/launch integration are not claimed. Custody remains operator-managed and defaults to read-only.
Validation: all 25 repository check scripts pass; seven Node tests pass with local Anvil and a read-only Bradbury check enabled; real GenSwarms Router/ObjectServer delivery passes. CI checks bundle reproducibility and runs the native and local-EVM suites. No funded Bradbury transactions were sent.
SwarmIDX publication is scoped only to genlayer@0.1.0 using the immutable source commit; existing package versions are unchanged. No cross-repository implementation dependency or full network E2E is required for this experimental package release.