The TAPS Architecture for Transport Services [6] providesa framework for the design of a protocol-independent asynchronousmessage-based transport API. While the traditionalBSD socket API [1] requires the user to make a choice aboutwhich protocol to use from the beginning, the TAPS APIfocuses on transport features and gives the transport stackitself the opportunity to select the most appropriate protocol.This flexibility also supports deployment of new protocols,such as QUIC, because the application does not need tochange in order to benefit from such new innovations. Thisposter defines two API mappings for QUIC, either exposingmultistreaming explicitly to the application or providing away to utilize multistreaming without application input.