Objective
The idea is to extend BlP37 (Bloom Filters) to support all InstantSend related messages ("ix" and "txlvote"). Dash Core already supports Bloom Filters for regular transactions.

Reasoning
The benefit is to reduce network traffic to SPV (or filtered nodes). The current Dash Wallet for android is aware of the "ix" and "txlvote" messages and it listens for them to add InstantSend transactions to its wallet as they are received and to know if the masternode quarum validates InstantSend transactions (sent and received). Dash Wallet uses dashj as the layer that interfaces with the Dash P2P Network. Other apps may use dashj or have their own implementations that could benefit.

What Needs to be Added to Dash Core
There would be two new messages to cover - both of which are announced to peers using "inv" messages. The peers receive "inv" messages, then request data they don't have with "getdata".

1. "ix"
2. "txlvote"

IX("ix") [Already done]
From RelayTransaction we can see that bloom filters are used with InstantSend transactions as they are with PrivateSend and regular transactions:
https://github.com/dashpay/dash/blob/master/src/net.cpp#L2102

Therefore I would say no changes are needed with "ix".

Transaction Lock Votes ("txlvote")
It appears that transaction lock votes are generated by masternodes and then relayed or they received by a node and relayed to other peers with an "inv" message. This is done first by CTxLockVote::Relay() which calls RelayInv found here: https://github.com/dashpay/dash/blob/master/src/net.cpp#L2136. As one can see, RelayInv does not use any filters to determine what applies to each node. PushInventory is called on each peer and is found here: https://github.com/dashpay/dash/blob/master/src/net.h#L526. It does not use filters either.

My suggestion here, in PushInventory or RelayInv is to determine the transaction associated with the Transaction Lock Vote (CTxLockVote) and then call pnode->pfilter->IsRelevantAndUpdate(txlvote.txHash) to determine if that Tx Lock Vote should be sent to that peer in the next inventory message sent.

There may be a better way to achieve this.

Sources:
Dash Wallet: https://github.com/HashEngineering/dash-wallet
dashj: https://github.com/HashEngineering/dashj
BIP37: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki