chore: enable arbitrum bridge in prod

[kaladinlight]

Description

Turn on the feature flag for arbitrum bridge/claim in production environments

Issue (if applicable)

N/A

Risk

High Risk PRs Require 2 approvals

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

Testing

Reference the following PRs for testing steps:

• feat: arbitrum bridge claim #7563
• feat: arbitrum bridge swapper #6977

Engineering

☝️

Operations

• 🏁 My feature is behind a flag and doesn't require operations testing (yet)

☝️

I am not sure how much testing has been done for arbitrum bridge/claim thus far as it has been behind a feature flag, so please ensure there is high confidence in this feature accordingly before release.

Screenshots (if applicable)

[NeOMakinG]

gm

https://jam.dev/c/4f82f1e5-6164-4458-b4c0-4749fdb87465

We need to add a text No claims available and No pending claims if we don't have any of them

[gomesalexandre]

Tested locally with build and app env.

While this functionally is almost ready to go, requesting changes re: two spotted bugs:

• Outbound deposit is wrongly tagged as "Withdraw Initiated"
• Small amounts are rugged at claim confirm step

Also added some suggestion - though not a blocker for release - re: tagging claims as claims in Tx history.
And another one which may require product input, but IMO is a blocker for release, re: complete state showing "Trade Complete / received" despite the Tx being a withdraw initiation.

Swapper Arbitrum Bridge

• Token deposit - inbound ✅

https://jam.dev/c/4fe1ccbb-64d8-4a40-be64-0e7852cb80e6

• Token deposit - Outbound 🚫

Outbound is tagged as "Withdraw received"

Looking at the translation for this, this is the culprit - there is no concept of withdraw received, only claim received

web/src/assets/translations/en/main.json

Line 663 in 01384d6

"finalizeInboundTransfer": "Withdraw Received",

• Token withdraw - inbound ❓

https://jam.dev/c/bacd18a4-c267-4061-8afc-546e2bec40f4

Not sure whether or not we consider this an issue for launch, but status detection is wrong here i.e:

but:

We should probably accomodate complete status detection here to handle the Arb Bridge deposit case and display something different than "Trade Complete" (the trade isn't complete just yet, and this isn't a trade per se), as well as a better copy than Successfully received <asset> on Ethereum., as the asset was not received.

• ETH Withdraw - inbound ❓

LGTM except for the same "Trade Complete / fundus received" issue here

https://jam.dev/c/60a91cea-a060-413d-9d20-ce2b939c8d26

• Claim tab - claims look sane against arb Bridge

• ETH claim 🚫

https://jam.dev/c/62f1848d-8bd0-4b1f-b38c-8ad5fb1c6e23

• Small amounts are rugged with fp precision and displayed as 0

- Wondering if we want to tag `executeTransaction` as claims in Tx history?

• Token claim ❓

https://jam.dev/c/245e8753-5cb2-45ad-874f-899ea3116ce0

Functionally does the do, but wondering if we want to tag executeTransaction as claims in Tx history? https://etherscan.io/tx/0x48bd40a3cac5d25b21d2ae31375f6c273a3fe37f78cfca385e05a948038a1c57

[kaladinlight]

Requested changes have been addressed in:
#7643 (precision loss)
#7645 (claim tx parsing)
#7647 (deposit tx parsing)
#7656 (no claims status text) - pending review

[gomesalexandre]

gm https://gist.github.com/gomesalexandre/63c0188b9e1517d24d809da9fd08c1b5