For single row inserts the undo generated should be 64 bytes per row, however if it is the first change in a transaction then there is another 40 bytes for the ITL change and the transaction table undo. That is about what you have observed.

If the application can use array inserts then the undo generation could be cut dramatically. Array inserts generate a single undo record for all rows inserted to a particular block. That undo record takes 68 bytes, plus 2 bytes per row inserted. Similarly, you could save undo (and redo, and lots more) by reducing the commit frequency.

I'm doing a hypothetical resourcing model for a very high insert requirement. I'm just doing INSERTs into a non-indexed table for now. I've modelled the actual data blocks, and the redo. Now I'm doing the undo, but it seems too big for what it needs in order to rollback the transaction. From V$TRANSACTION, I get around 75 URECs per UBLK. When I dump the block, it seems to confirm the number as 78. Ignoring header overhead, this would make each undo record about 105 bytes (8k block), which seems a bit big.