I can provide some insight though i've pinged one of the omnicore dev's to assist with some of the more base line bitcoin protocol details.
For full details on the Omni protocol spec please see: https://github.com/OmniLayer/spec

While all transactions on the OmniProtocol are sent over the Bitcoin network there are a few general rules on the structure of an Omni protocol transaction (and thus a tether send transaction) :

First since it is on the bitcoin network, it will have to be a valid bitcoin tx at the end of the day. So miners fee's signing inputs/outputs etc.. all have to comply with a normal tx.

Next, The sender is determined by the first input in the tx. So you can fund the tx from several address if needed, however only the first input in the tx will signal to the Omni protocol who is sending the Omni Assets.

The receiver is chosen/indicated by the last output address that is not the sender. So if you want to send any extra btc change back to yourself or to a different address specify those first.
Signaling The receiver address only needs a fraction of btc,  right now we're using 0.00005460 btc as that 'reference output amount'.

Finally the guts and glory of an Omni Protocol transaction, the data packet encoded into OP_RETURN.
This is a hex encoded payload that has a few different components.
From your example above you already have the ASM OP_RETURN 6f6d6e69000000000000001f000000002faf0800 OP_EQUAL

If we break it down we get:
Bitcoin protocol:
 OP_RETURN  opcode/operation

Omni protocol (hex encoded values):
 6f6d6e69 -  string 'omni' used to indicate/mark the tx is for the omni protocol to Omni software
 0000 - Next 4 bytes indicate the Transaction version, at present simple send is version 0
 0000 - next 4 bytes indicate transaction type, simple send is type 0
 0000001f - Next 8 bytes, are used to represent the token property id of tokens being acted upon, In this case Tether is Property id 31, 1f in hex
 000000002faf0800 - Next 16 bytes are used to indicate the number of tokens being sent as a whole number.
  Note: The omni protocol has 2 concepts for tokens, Divisible like bitcoin, fractional amounts. And not indivisible, smallest unit represented is 1, no fractional amounts. When encoding
  amounts for the payload divisible amounts are converted to whole number representations (multiple by 1e8). Since Tether is a divisible property, sending an amount of 8, you would
  hex encoded 800000000 * 8 *  1e8)

Bitcoin protocol :
 OP_EQUAL -  You actually do not want this, remove it. THE OP_RETURN is a data payload, not actually an addresses.

A few more notes/things to understand.
The Omni Protocol is not Input/Output based. I.e. the output of a 8 tether send is not needed/relevant when sending 8 Tethers later on.
The Omni Protocol is basically a state machine, where every transaction you send is just an instruction that state machine uses to update a balance or process a request.
So when you send 8 Tether, you are basically sending the instructions to the Omni protocol that say, transfer 8 Tether from address X to address Y.
If all the validation/security/tx checking are verified then the software processes the request and balances are updated/funds are moved.

I've updated your tx (without signatures) to show what the 8 Tether simple send would look like using only the 1 input (minimize tx size)


and if we decode it to show both the BTC and OMNI decode info we get


If you were to sign this tx with the required number of signatures it would be valid to send.