This challenge has two pages, a fairly functionless outer page, and an inner page with a postMessage listener that performs some rich hydration of an object before using it to make a mocked post request to a nonexistent API endpoint with a body derived from the message. There is no origin check on the listener, the page is frameable, and there is not much else going on here, so it is clear that the way to achieving the XSS involves framing the inner.html page from an attacker page and sending it crafted messages.
The inner.html page has the following custom JavaScript to implement a postMessage event handler.

The message event is passed to a rehydration function that takes a from and to value from the message data and uses lodash's get method to get a potentially nested property from the event and assign it as a potentially nested value to the event.data.base object with lodash's set method. Notably, this is getting a potentially nested value from the event, not event.data. This oversight allows for very interesting behavior. By reading a property from event.target, we can read from the global window object of the inner.html page. This allows us to set a wide variety of values on the event.data.base object before it gets passed to JSON.stringify later in the code.
There are two crucial pieces here that allow this strange code to lead to XSS. The first being the ability to copy a property from window to a nested value on the event.data.base object. The second being the call to JSON.stringify on the hydrated version of event.data.base.
Per the MDN docs, we can see that JSON.stringify will conditionally call nested or top level toJSON functions on objects being passed to JSON.stringify, potentially even with a controllable string as the first argument in nested cases.

This allows us to craft a payload that copies event.target.eval to event.data.base as a somejstoexecute.toJSON property. This will lead to the creation of an object like the following:

This object when passed to JSON.stringify will have its nested toJSON function called with the property name of the parent object, leading to eval being called with alert(origin).
A full payload to accomplish this can be seen here.

It abuses the postMessage listener to copy eval onto the object being stringified in such a way that it gets called as the toJSON function with an attacker controlled string passed as the first argument, leading to XSS.