TP deposit & async flow auth (deposit/withdraw accounts + CCT) - #814
TP deposit & async flow auth (deposit/withdraw accounts + CCT)#814krebernisak wants to merge 24 commits into
Conversation
|
👋 krebernisak, thanks for creating this pull request! To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team. Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks! |
| notificationTarget: address; | ||
| /// Only messages from this jetton wallet are forwarded (prevents spam from other jettons). | ||
| /// Set on init — OAA address is derived from (code, owner, notificationTarget) only. | ||
| allowedJettonWallet: address?; |
There was a problem hiding this comment.
If this gets deployed with Deploable, there's no need for this to be optional
| forwardPayload: msg.forwardPayload, | ||
| }, | ||
| }); | ||
| reply.send(SEND_MODE_CARRY_ALL_REMAINING_MESSAGE_VALUE); |
There was a problem hiding this comment.
We want to reserve some balance, either here or through Deployable's Deployable_InitializeAndSend
|
|
||
| /// Sent by the pool after successful initialization, confirming the account is ready. | ||
| /// The pool identifies which OffRampAccount replied from `in.senderAddress`. | ||
| struct (0xb2e46750) OffRampAccount_Reply { |
There was a problem hiding this comment.
nit: The message name is not very descriptive. OffRampAccount_Initialized may be a better option
| bounce: BounceMode.RichBounce, | ||
| value: 0, | ||
| dest: getJettonWalletOf(data), | ||
| body: AskToTransfer { |
There was a problem hiding this comment.
followup: pontentially, we could just send CCIPSend to the router instead
writing it here so we don't forget
| /// `OffRampAccount`. The token pool (which knows the Deployables setup) is responsible for | ||
| /// deriving the account via Deployables to authenticate deposits. See | ||
| /// `TokenPool_DynamicConfig.allowedDepositNamespaces` / `TokenPool_AdminConfig.deployableCode`. | ||
| fun calcAddressOfOnRampAccount( |
There was a problem hiding this comment.
Is this outdated? I think this is unused and has been replace by deriveDepositAccount. We shouldn't be using the OnRampAccount_Data to derive the address if the contract gets deployed with Deployable
| val context = lazy BurnMintTokenPool_BurnContext.fromCell(msg.forwardPayload!); | ||
| val operation = context.forwardPayload.load(); | ||
| // TODO: is this check necessary? | ||
| assert(context.wallet == pool.data.jettonClient().walletAddress(), BurnMintTokenPool_Error.UnexpectedBurnBounce); |
There was a problem hiding this comment.
I don't see the point. What are you protecting from? The forwardPayload is arbitrary data. You've already check that sender is your own wallet address and that the initiator was you.
| mutate self, | ||
| sender: address, | ||
| queryId: uint64, | ||
| allowedDepositNamespaces: map<uint32, bool>, |
There was a problem hiding this comment.
You can use void type. See doc here
| allowedDepositNamespaces: map<uint32, bool>, | |
| allowedDepositNamespaces: map<uint32, ()>, |
Summary
Eliminates queryId-keyed pending storage (
pendingBurns,pendingMints,pendingReleases,pendingLocks) from all token pool variants, enabling concurrent cross-chain operations without storage collision or circuit breaker limits. The design evolved through two phases within this PR:forwardPayloadWhat Changed
OffRampAccount (new):
CCT Burn Flow:
forwardPayloadon burn messagesCCT_AskToBurn,CCT_BurnNotificationForMinter,CCT_ReturnExcessesBackall carryforwardPayloadBurnMintTokenPoolsendsCCT_AskToBurnwith context embedded, finalizing the burn directly — no proxy contractToken Pools (3 files):
BurnMintTokenPool: Burn path uses direct CCTforwardPayloadflowLockReleaseTokenPool: Release flow uses OffRampAccount for async continuationLockReleaseLockboxTokenPool: Both lock and release flows use OffRampAccountToken Pool Entrypoint
entrypoint.tolk:onLockOrBurnTransferwithtry/catcharound forward payload decodingbestEffortReturnTransfer: Returns custody to sender on recoverable failuresnotifyLockOrBurnFailure/reserveLockOrBurnFailureValue: Pool balance protectionOther:
consumeInboundRateLimit/consumeOutboundRateLimitfunctions shared across pools