Hey Igor Yalovoy 🧙thanks for the questions!

• To my understanding transactions are submitted to network from Relay contract which means msg.sender will have Relay address not user wallet address? Is this correct?

Yeah, it is a common problem for third party relayers (e.g. either a relay contract or the transaction is msg.sender).

I’m hoping Ethereum will support a new opcode targetContract.callWithSigner() to replace the msg.sender with the signer’s address. (Future blog post).

Until then, all relay services need to use a proxy in the middle. e.g. so Relay.sol calls out to a ProxyAccount.sol that calls to the target contract. We are working on a protocol independent approach for it now https://github.com/anydotcrypto/metatransactions/ so any project could adopt it. e.g. minimal proxy account contract that just takes care of replay protection.

• Compensation and deadlineBlockNumber are super interested concepts. What are the limits for these? Specifically what is the upper limit for compensation? And from what kind of pool it is paid?

For compensation, we have it set at 0.05 eth (still in beta). As people use the service, we’ll get a better idea on appropriate limits/expectations, e.g. should we use compensation as insurance to cover value of transaction? or as a guarantee that we will excessively credit the user’s account if we offer a bad service? For payment, it comes from our own account in a timely manner, otherwise our stake is slashed.

For the deadlineBlockNumber, it is a promise from us the transaction will get confirmed within 100 or 400 blocks *in the worst case*, but we always aim for ~2–5 blocks. Internally, we are discussing having a fixed deadline of 100 blocks for an “accountable queue”, so no matter what it will always get confirmed within 100 blocks. Then we can have several “unaccountable queues” that lets the user a max gas price (e.g. 100 gwei) — for less critical transactions.