Blocking: code duplication. Everything from here to the end of this function is a copy of flatten in src/stringify.js with await added in a handful of places. That means:

• The sparse-array heuristic, the __proto__ guard, the Temporal cases, the typed-array subarray handling, and every error message now have to be maintained in two places.
• Bug fixes and new type support added to stringify won't automatically apply to stringifyAsync (and vice-versa). There's no test that asserts the two implementations stay in lockstep beyond the fixture round-trip — and even that test will silently keep passing if both files happen to develop the same bug.
• The stringify_primitive helper at the bottom of this file is also duplicated verbatim.

Please refactor so there's a single source of truth — see the top-level review for suggested approaches. Option 2 (walk-and-resolve, then delegate to existing stringify) would let this file shrink to ~50 lines and would naturally address the parallelism comment too.

Blocking: Promise identity is never recorded.

await thing is performed before indexes.has(thing) is consulted on line 63, which means the Promise itself is never inserted into indexes. If the same Promise reference appears multiple times in the graph it will be await-ed every time it's encountered — for an already-resolved Promise this is just wasted work, but for a slow Promise that's referenced N times it's an N-way serial wait (because traversal is sequential — see other comment).

More importantly, this is a behavioral divergence from stringify's identity-based dedup contract. Users who carefully share a single Promise across the graph expecting it to round-trip as a shared reference will instead get the resolved value's identity-dedup behavior, which only kicks in if the resolved value is itself a non-primitive === to something previously seen. Two distinct Promise.resolve({a:1}) calls in the input will not dedup, even though sync-shared {a:1} does.

At minimum, please:

1. Record the Promise in indexes before awaiting (pointing at the same index that the resolved value will occupy), so subsequent encounters of the same Promise short-circuit.
2. Add a test for stringifyAsync([p, p]) where p is a slow promise, asserting it is only awaited once (use a counter in the executor).
3. Document the dedup semantics for Promises in the README.

Performance: independent Promises are awaited serially.

Because the traversal is a depth-first recursive await, two sibling Promises that aren't already started will run sequentially. Consider:

await stringifyAsync({
  a: new Promise(r => setTimeout(() => r(1), 100)),
  b: new Promise(r => setTimeout(() => r(2), 100))
});

This takes ~200ms instead of ~100ms. The README example happens to work because fetch() starts the request eagerly, but Promises produced lazily inside reducers (or via new Promise(executor)) will be paid for one at a time.

A two-pass approach (collect all Promises during a sync walk → Promise.all → re-walk synchronously) avoids this entirely and is one more reason to pull the async concern out of the stringification logic. Not strictly blocking on its own, but combined with the duplication issue it's another argument for restructuring.

Minor: indexes.set(thing, index) here only registers the resolved value (since the original Promise was already overwritten by await on line 54). Worth a comment noting that thing here is guaranteed to be the resolved value, not the Promise — or, better, also record the original Promise (see the dedup comment) so the sharing contract is consistent with sync stringify.

Question: should reducers receive the Promise itself, or only the resolved value? As written, a reducer like MyPromise: (v) => v instanceof Promise && ... can never match because thing has already been awaited by the time we get here. That's probably the right default, but it deserves a line in the README — particularly because users coming from libraries like superjson may expect the opposite.

If you keep the current behavior, please also add a test for an async reducer that returns a thenable resolving to another thenable (which currently works, because flatten is recursively called on the awaited reducer output) — and a test for an async reducer that resolves to a function, asserting it produces the expected Cannot stringify a function error with a useful keys path.

Nit: when this DevalueError is thrown for a function (or symbol) that came out of an awaited Promise, the keys array correctly reflects the path to the Promise, but thing is the resolved value. The error message is identical to the sync case, which is fine, but a user debugging "my fetch returned a function somehow" loses the breadcrumb that this came via a Promise. Optional: append (in resolved promise) to the message or keys when applicable.

Drive-by: the comments explaining the sparse-array heuristic that exist in stringify.js (lines 110-164) didn't get copied here. That heuristic is non-obvious and the comments are load-bearing — if for some reason this file survives the refactor, please port them over.

Great that you're round-tripping every existing fixture through stringifyAsync — this catches the easy regressions. Please add tests for the cases flagged in the implementation:

• Same Promise referenced twice in the graph → assert it is only awaited once (use a counter in the executor).
• Two sibling Promises with setTimeout → assert total time ≈ max(durations), not sum (i.e., they ran in parallel). This will currently fail; it's the test that will guide the parallelism fix.
• Promise resolving to a value that already exists elsewhere in the graph → assert dedup works.
• Cycle that includes a Promise (e.g. obj.p = Promise.resolve(obj)) — there's no test for this and it's a tricky case worth pinning down.
• Async reducer whose returned thenable rejects → assert the outer stringifyAsync rejects with that error.

thenable here is a synchronously-resolving thenable. Worth also testing:

• An asynchronously-resolving thenable.
• A thenable whose then throws synchronously (which should reject the returned promise).
• A thenable whose then calls reject.

The typeof thing.then === 'function' check in the implementation is a duck-type that will treat any object with a .then method as awaitable (incl. ones the user didn't intend to be awaited) — make sure there's a test demonstrating this is the intended contract.

Worth documenting:

1. Promises are awaited sequentially during traversal (or, ideally, fix that and document parallelism).
2. Promise identity is not preserved — a Promise referenced twice does not produce two references to the same resolved value unless that resolved value is itself an identity-shared object. (Or, ideally, fix this and document that it is preserved.)
3. Async reducers receive resolved values, never raw Promises.
4. A rejection anywhere in the graph rejects the returned promise.
5. There is intentionally no parseAsync — async is a stringification-only concern (this is correct, but readers may wonder).

The section header reads ### stringifyAsyncandparse which is a little misleading — `parse` isn't doing anything async, it just happens to consume the output. Consider renaming to just `### `stringifyAsync and noting in prose that the output is consumed by the existing parse.