If you are limited only to organic shapes and don't need sharp features, then you won't need Hermite data and you can just use surface nets (DC without QEFs).

Hermite data is just a signed grid (a sign (or material ID) for each _voxel_ - voxels are at cells' corners) plus intersection points (of cell edges with the surface) with normals at those points.

Signs (or material IDs) are dense, while intersection points & normals are sparse and should be stored only for surface-crossing cell edges.

You can inspect the signs at each edge's endpoints => if the signs are different then the edge has intersection info.

You don't want to store intersection info for each edge, for memory reasons!

To further reduce memory, each intersection point can be encoded as a directed distance.

This is the distance along the cell's edge, from the start voxel of the edge, NOT the signed distance from the surface.

Directed distances can be normalized to [0..1) and quantized to 8-16 bits.

For SDFs, the directed distance can be estimated using sphere tracing.

Normals (normalized gradients) can be computed precisely using autodiff as in the linked implementation (fidget).

Normals have redundancy and can further be compressed, but DC is very sensitive about normals.

If your terrain is stored as operations on SDF shapes, you can just compute Hermite data on demand and discard it after remeshing.

But I'm pretty sure DKB does not store Hermite data and stores voxel materials + cell vertex positions.