"Virtual Rollups" via Transfer Hooks

[sergfeldman]

Basically the idea of being able to spend money on a Ubiquity debit card but deduct directly from a user's wallet balance. However, we can create a "virtual rollup" by deducting on the next transfer via a transfer hook. It might be cheaper to do a single debit to roll up all transactions vs every transaction debit in regards to gas fees.

ubiquity/research#2

[0x4007]

We need to create a research specification to have a transfer hook contract to be able to perform this behavior of rebasing a user's uAD balance before a transfer. It would be even more interesting if we had an off-chain oracle for the amount to be debited (so that it can change as many times as needed throughout the day - e.g. a user makes 20 debit card transactions)

Then the next time that the user wants to interact with their uAD with a transfer the transfer hook will rebase the user's balance from e.g. 1000 uAD to 850 uAD after the 20 debit card transactions from that day.

The purpose of the rollup is, of course, to save on gas fees by rolling up the user's many debits into a single on-chain transaction.

[0x4007]

• The off-chain oracle can be represented as "user delegated balance" where the amount begins with the amount of Ubiquity Dollars in the user's wallet, pre-transaction.
• Next, a delegate service such as the Ubiquity Card modifies the "user delegated balance".
  • This is stored in an off-chain database, or on Gnosis Chain as the gas fees are negligible.
  • In this case, every time the Ubiquity Card is debited in the real world, it will subtract from the "user delegated balance."
    • as debitCard role, to enable access control management.
  • This architecture allows "on-chain Ubiquity Dollar balance" delegation for various off-chain contexts.
• Finally, the pre-transfer-hook ensures that the user's balance is synchronized with the "user delegated balance"
  • This means that when the user transfers (this includes ANY movement of Ubiquity Dollars, including for redeeming collateral, or for swaps.) before the transfer begins, the user's balance is debited (burned) from.
  • For security reasons, it only makes sense to enable support for subtracting/debiting/burning Ubiquity Dollars from one's on-chain balance via this pre-transfer-hook.
    • This can be easily handled with our protocol access control manager by enabling only burn permissions on the "user delegated balance" transfer-hook contract address.

Final note, the Ubiquity Card service (off-chain) has a max spend limit of the user's current on-chain Ubiquity Dollar balance. Afterwards, it will read from the current balance provided by the "user delegated balance" oracle/API. Each debit on the debit card will subtract from the "user delegated balance."

---

What does the architecture look like to let the user activate a transfer hook via an approval call? I think it would be most comforting if users must deliberately opt in to enable delegated balances, otherwise there would be a lingering sense of insecurity for users that their money can be taken by the Ubiquity team or by hacks at any time.

[0x4007]

Request for comment @zgorizzo69 @rndquu

[rndquu]

Sync gap

Traditional banks maintain a single source of truth (i.e. DB)

In the proposed architecture we should maintain 2 sources of truth:

1. off-chain Ubiquity Card service (i.e. DB with user balances)
2. on-chain UbiquityDollar contract with user balances

Maintaining 2 sources of truth we have a "sync" gap when user pays with his Ubiquity debit card.

Example (user balance 100 USD on-chain and off-chain):

1. Time: 12:00:00. User pays 100 USD with his debit card (on-chain balance: 100 UAD, off-chain balance: 0 USD)
2. Time: 12:00:00. User transfers 100 UAD to somebody (on-chain balance: 0 UAD, off-chain balance: 100 USD)

So on next trasfer code inside a transfer hook will fail to deduct 100 USD (which came in off-chain) because there is nothing to deduct

Flow

Consider an example with onchain confirmation (with successful result):

1. User wants to buy a T-shirt in an online store for 10 UAD
2. User enters his Ubiquity Card number
3. User's card number is sent to the "Ubiquity Card Service" (which has allowance over user's balance)
4. "Ubiquity Card Service" sends transfer transaction to gnosis chain that moves user's 10 UAD to the merchant (here we omit the "who pays for gas?" question because gas prices are really low in gnosis chain)
5. "Ubiquity Card Service" waits 40 seconds for 8 block confirmations in gnosis
6. "Ubiquity Card Service" sends a success webhook to the online store so that it could display a success message

Here on step 3 we should somehow distinguish a real card holder with an adversary who knows the card number. So we need an additional step of authentication (sms, push, OTP, etc...)

So basically we are sending a transaction on behalf of a user. I don't get why user should take additional risks by allowing some address his funds while he can simply use any wallet, sign transaction and send it without any 3rd party services.

[0x4007]

Traditional banks maintain a single source of truth (i.e. DB)

If the user wants to use the debit card feature (or any other off-chain extensions of the Ubiquity Dollar economy) the user is required to opt in to this "delegated balance service." Now this is the singular source of truth for the balance of that user. Once the user has enabled the "delegated balance service" on the next on-chain transfer of uAD, the balance will be rebased to what the "delegated balance service" thinks it should be.

If a user is not opted in, then they can not use any of these features with prevents any of these issues from happening in the first place. Meaning that by default, the single source of truth will be the user's on-chain balance as we would traditionally expect for any normal stablecoin project.

Time: 12:00:00. User pays 100 USD with his debit card
Time: 12:00:00. User transfers 100 UAD to somebody

I also think this is exceptionally difficult to get a transaction included and the block validated all in the same millisecond that the debit card payment was made and is checked by our server. Maybe possible so we should think about this more carefully.

Flow

5. "Ubiquity Card Service" waits 40 seconds for 8 block confirmations in gnosis

I am not sure that the traditional finance system is compatible with this. I would imagine that the point-of-sale system would throw an error for such a long card transaction timeout. Also from the user's perspective: imagine going to a fast food restaurant and spending 40 seconds to buy a snack. I would not consider that as acceptable.

Here on step 3 we should somehow distinguish a real card holder with an adversary who knows the card number. So we need an additional step of authentication (sms, push, OTP, etc...)

I always like to default to Gnosis Safe because they support push notifications and transaction approvals on the iOS app, which is a very convenient form of on-chain two-factor authentication.

I don't get why user should take additional risks by allowing some address his funds while he can simply use any wallet, sign transaction and send it without any 3rd party services.

There is no way that we can offer a fully decentralized debit card. It must have a centralized component unfortunately due to laws and regulations. If you know of a way to hop on to traditional finance payment rails in a totally permission less way then we will absolutely do that. However as of now, there must be KYC for example, and the card must be authorized (accepted) by merchants in specific geographies following geographic specific regulations.

I'm unsure if I addressed all of your points fully.

Fiat Liquidity

There is one clarification I need to make in regards to liquidity in case it is not clear:

When we issue debit cards, I presume that we will need to have a fiat bank account with liquidity (e.g. $1M USD for all the early customers) and that balance must be topped up/managed daily in order to settle payments in the fiat world. So when a transaction happens with a merchant, it all happens on the fiat side.

However, because Ubiquity is providing that fiat liquidity, we must be made whole from our customer/user. The way we do this is by liquidating their on-chain uAD from their wallet so that they can't redeem collateral or spend it elsewhere on chain.

[rndquu]

If the user wants to use the debit card feature (or any other off-chain extensions of the Ubiquity Dollar economy) the user is required to opt in to this "delegated balance service." Now this is the singular source of truth for the balance of that user.

So we should somehow block on chain transactions for that user while he is opted in to the "delegated balance service", right?

[0x4007]

I think it's easy to control transfer behavior on-chain including blocking with transfer hooks.

This question seems to be less around technology and more around strategy.

[rndquu]

I think it's easy to control transfer behavior on-chain including blocking with transfer hooks.

This question seems to be less around technology and more around strategy.

I'm trying to understand how to prevent double spending from off chain and on chain user's balances.

So, from what I've understood so far, in case a user wants to opt in for the "delegated balance service" we should:

1. Block user's on-chain transfers and operate only with an off-chain balance
2. Sync off-chain balances with on-chain ones from time to time

[0x4007]

1. Block user's on-chain transfers and operate only with an off-chain balance

Unfortunately this sounds exactly like depositing the tokens into a smart contract which defeats the vision of being able to keep your Ubiquity Dollars liquid in your wallet, while being able to spend them in the real world. Alternatively we could consider spend limits with the debit card and actually make their uAD balance negative (overdraft.)

Sybil attacks should be mitigated as debit cards presumably all require some form of KYC verification.

The overdraft idea is not ideal, but it will handle the edge case I replied to earlier with:

I also think this is exceptionally difficult to get a transaction included and the block validated all in the same millisecond that the debit card payment was made and is checked by our server. Maybe possible so we should think about this more carefully.

2. Sync off-chain balances with on-chain ones from time to time

This will be synchronized in the pre-transfer-hook, every time transfer is invoked on the Ubiquity Dollar.

[rndquu]

Alternatively we could consider spend limits with the debit card and actually make their uAD balance negative

This does not eliminate double spending but if there is a form of KYC on the "debit card side" then we could charge negative in such cases

[0x4007]

I also think this is exceptionally difficult to get a transaction included and the block validated all in the same millisecond that the debit card payment was made and is checked by our server. Maybe possible so we should think about this more carefully.

Another kernel of an idea that isn't completed but maybe could inspire something more fleshed out: what if we take inspiration from optimistic rollups, where we optimistically assume that everybody is a good actor, but if we detect any foul-play (attempted double spend) we can post the attestation and retroactively undo things on chain.

[rndquu]

I also think this is exceptionally difficult to get a transaction included and the block validated all in the same millisecond that the debit card payment was made and is checked by our server. Maybe possible so we should think about this more carefully.

Another kernel of an idea that isn't completed but maybe could inspire something more fleshed out: what if we take inspiration from optimistic rollups, where we optimistically assume that everybody is a good actor, but if we detect any foul-play (attempted double spend) we can post the attestation and retroactively undo things on chain.

This is actually an overdraft. On any foul-play with charge the debit card and make it's balance negative (overdraft).

So overall UAD <=> debit card is a complex task. We should research the topic thoroughly.

[0x4007]

Monitor Pending Transactions

Another potentially straightforward and simple solution: when the user swipes their debit card, our backend should monitor pending on-chain transactions. We can proactively deduct from their "delegated balance" based on the amount pending in the transaction.

This does not solve for MEV related transactions yet, but it could be a step in the right direction.

[Draeieg]

@rndquu something @pavlovcik and me just talked about is block reorgs, in that scenario double spending could be possible but so far they seems incredibly rare

[rndquu]

block reorgs are not rare, https://etherscan.io/blocks_forked => 38 block reorgs in the last 24 hours

[0x4007]

Nice find. I just looked through the last 100 days quickly and see that a block reorg of a depth of 1 block is very common. I didn't see any instances of more depth in my quick look.

[Draeieg]

set a limit transfer hook where you wallet balance cant get lower than the card limit

by example:

• you have an ubiquicard with a 1000$ spending limit
• you have to hold at least 1000 uAD in your wallet for the card to work

users can configure their spending limits in an app and the only requirement other than what the card issuer gives will be having uAD already in your wallet

this way double spending is impossible due to the fact you're always restricted to hold money to pay us later in the event of an error

also we can have the added advantage of that money not necessarily being uAD in a wallet but also LPs in pools we control so the user can still earn yield on their money and in the event they over spend we take a protion from their LP to represent that missing money

[0x4007]

I'm not sure if I'm understanding you correctly but the proxy smart contract is our transfer hook contract. When I'm on my computer next time perhaps I can explain its currently implemented architecture better.

Our protocol currently has an address lookup capability to associate a uAD transfer initiated from an address and to call a specific smart contract before completing the transfer call.

---

In case I understand you correctly in that you're describing an opt-in flow:

I think a more elegant opt-in could be a function they call which will add their address to a previously deployed debitCardDelegatedBalance transfer hook contract. This transfer hook will check our off chain oracle for outstanding debits and will execute them before the transfer call is completed (rebase the on-chain balance)

Next, in our debit card app, the user will need to provide a signature from their wallet to confirm that their wallet is owned by the same user that is authorized to use the debit card (KYC)

---

Final details to think through might be what information we will be transmitting in this oracle. Hopefully just what the delta in balance is sufficient (e.g. -105 meaning they owe us 105 uAD). Worse case scenario is that we need to send information that dox's the user on chain.

[rndquu]

I'm not sure if I'm understanding you correctly but the proxy smart contract is our transfer hook contract

Yes, I wrote about a proxy contract and then realised that the UbiquityContract itself (with transfer hooks) is basically this "proxy contract"

This transfer hook will check our off chain oracle for outstanding debits and will execute them before the transfer call is completed (rebase the on-chain balance)

This transfer will be a multi-block (at least 2) transaction:
Block 1: user initiates a transfer
Block 2(ideally): oracle sees the transfer from block 1 and sends "rebase" balance transaction

Also there are 2 ways to confirm transfer at block 2:

1. After balance rebase user can call "confirmTransfer()" (i.e. user pays for gas)
2. Oracle executes initialized transfer transaction (i.e. oracle pays for gas or relays the tx and subtracts gas fees from transfer amount)

[0x4007]

No the rebase happens inside of the transfer transaction. It's all atomic.

Here's a demo transaction trace of an old transfer hook we enabled that would mint governance tokens as a reward for buying our dollar when it falls below peg on our curve metapool.

At least that's how I remember it but the math doesn't seem to check out upon a cursory glance at the amounts going in and out. The specific function name CurveUADIncentive._getPercentDeviationFromUnderPeg that is called inside of the transfer hook does support my memory though.

Here is the etherscan link of the same transaction.

[rndquu]

No the rebase happens inside of the transfer transaction. It's all atomic.

If by "atomic" you mean that transfer happens in a single transaction then it can't be atomic because there is an oracle responsible to fetch balances from an off-chain service and post updated balances back on-chain. Oracle is an async service so chances are that oracle won't be on time to include the "rebase" transaction in the same block with the user's transfer transaction.

[0x4007]

I'll need to think on this more then. I don't have an answer now.

[0x4007]

I think we're going to need to use account abstraction (smart contract wallets) instead of using transfer hooks. This makes me think that it might be worthwhile to remove transfer hooks from the updated deployment, as they incur additional gas fees and we have not found good use cases for them.

[rndquu]

We're using transfer hooks on curve swaps:

• on selling Dollars we penalize users by burning more Dollars
• on buying Dollars we mint extra Governance tokens

So it seems that the "transfer hooks" feature is used.

[0x4007]

We disabled both of those hooks soon after deployment.

• The penalization was very poorly received by the community when FEI did it.
• Our economist illustrated an attack vector on how to farm governance tokens, so we disabled that hook as well.

[0x4007]

looks like the technology exists for this, just not on Ethereum

NEAR has asynchronous runtime. Meaning the transactions are not executed atomically, but instead split over blocks. This is required to make compute more efficient using sharding.

I leverage it by making a request transaction pending - wait for the external response.

https://x.com/ekuzyakov/status/1756812623117443226?s=46&t=bdMjuqzO5LYxLUsloRROxQ