In DPOS, blocks are produced in 10 seconds and thus we say the recommended confirmation time is 10 seconds. In reality, since blocks can be missed, the only way of being sure your transaction is in the consensus chain is if the block it is in has been approved by more than 50% of active delegates. By approved, I mean an active delegate signed a block that either contained the transaction or built the chain off a block which contained the transaction. Thus, the worst case confirmation time is actually around 8.5 minutes (actually I would say the true worst case confirmation time theoretically could be unbounded since delegate participation rate could be <50% for an indeterminate number of rounds). But in realistic scenarios, blocks are rarely missed and so one should not expect to wait more than 10 seconds to have their transaction confirmed with a high degree of probability.
So what I was thinking was that with just a little alteration to the protocol, we could get the recommended confirmation time below 1 second (I think, depends on network conditions). The idea is to take every transaction a user wants to broadcast (such as the signed transaction sent by a customer to a merchant) and send it to next 51 delegates (in block signing order) so that each of them can make sure the transaction is valid and send back signatures that claim that they will approve that transaction by their next block (this means include the transaction in the block unless it is already included in a previous block in the chain the delegate is building off of). They also keep that transaction in their working memory so that any new transaction received that would invalidate the prior transaction is considered invalid (a double-spend). If a delegate signs a block which doesn't approve the transaction they said they would approve by that block, the user can submit the signature to the network as proof that the delegate lied and get the delegate automatically fired. The reassurance that delegates will eventually lose their job if they break their promise to approve the transaction should be enough for the user to assume the transaction will go through. This means that as soon as all 51 of those delegates return their signatures for that transaction, the user can consider that transaction to be included in the chain even if it won't actually happen until a little later. Since, delegates are going to be online and responsive most of the time, it is unlikely that there will be a delegate in that group of 51 that does not respond extremely quickly. However, if it is the case that one of the delegates is not responding quickly or at all, then the user can just wait longer (usually 10 seconds but up to 8.5 minutes) to get confirmation of the transaction being included in the blockchain.
The other benefit of this approach is that it can be used with lightweight clients. As long as the lightweight clients are able to know who the current active delegates are (more on that later) and their ordering (just put the delegate's random number can be kept in the block header), then the signatures they get back from the 51 delegates should be enough assurance to the user that they actually received the assets they expected to receive. If the user later goes on the full client on their PC and finds out the transaction was never approved, they now can submit proof to get those delegates fired.
The lightweight clients need to know who are the active delegates in a given round. I think the way to make this work is to require the delegates to include the delta updates on the set of top 101 delegates in each block header. If the votes in the block causes delegate A at slot 101 to be replaced by delegate B, the block header for that block should note that A is out and B is in. Obviously all full clients on the network would require the block header deltas to be consistent with the vote changes in the block, or else the block would be invalid. Lightweight clients can rely on there being enough full clients online monitoring the full blocks and voting out any delegates that lie about the block headers. Under that assumption, the lightweight clients only need the block headers to keep the set of active delegates up-to-date over time.
I would also make sure to include in the block header two different Merkel tree roots. The first Merkel tree would have all the transactions in the block in a well-specified order as its leaf nodes. The second Merkel tree would have hashes corresponding to each trading asset pair in the decentralized exchange as its leaf nodes (again in a well-specified order). These hashes would be determined by taking the hash of the list of all transactions (in a well-specified order) defining all of the open market orders (up to that block) for the particular asset pair exchange market. With these two Merkel tree roots in the block headers, any full nodes (not just delegates) could provide Merkel branches to prove the existence of any transaction in the blockchain and prove to the lightweight clients that the client has received all open market orders (up to some block) for a given exchange market. This way lightweight clients could get accurate up-to-date information on the decentralized exchanges and get proof of any unsolicited funds sent to them more than 10 seconds ago (really more than 8.5 minutes ago to be safe), and all without having to burden the delegates to sign any statements. The lightweight (and full) clients would only burden the delegates for signatures for transactions that are sent from one party to another in a "real-time" environment (point-of-sale transactions) where sub-second confirmation times are desired.