Enbank docs
Withdraw to a debit card
The intended rail from a sealed vault amount onto an online debit card.
From vault to card
A withdrawal is the move that takes a sealed amount out of the private vault and onto an online debit card. The vault is where the amount stays private. The card is how that amount becomes spendable in the card network. They are different rails: the vault instruction settles on Solana after an Arcium computation, and the card leg is a fiat or card-network credit that has to be funded by a regulated issuer.
The intended sequence is:
- The client selects an asset and an amount already inside the vault.
- The client names a card destination it controls. That destination is a private input.
- The withdraw circuit checks the sealed balance and debits it inside the MXE.
- The callback publishes that a withdrawal settled for the account.
- An issuer, outside the MXE, credits the online card. That issuer is not this website.
Private inputs
The withdraw instruction is specified with three private inputs and one public fact.
| Field | Visibility | Why |
|---|---|---|
| Amount | Private | The size of the withdrawal is the value the vault exists to hide. |
| Asset | Private | The mix of cash, reserve, and encrypted dollar is part of the vault. |
| Card destination | Private | The card reference should not sit in a public account next to the address. |
| Account address | Public | Settlement still has to name which account the instruction belonged to. |
| Settled / rejected | Public | The chain needs a result. The result is a bit, not a figure. |
A card network will still see whatever the issuer must send to authorize a purchase. That leakage is outside the MXE. Enbank's seal covers the vault instruction, not the merchant descriptor on a later card swipe.
What stays public
The public record of a production withdrawal is that the account settled a withdrawal. Observers do not get the amount from that record if the callback accounts omit it. They also do not get the vault's remaining balance. The address remains the account, as described on Enbank.
Rejected withdrawals should fail closed: the sealed balance is unchanged, and the callback still avoids writing the attempted amount. A public failure reason that includes the amount would break the same rule.
Card data
The production card leg needs an issuer integration this repository does not contain. The fields that integration would have to keep off the public chain:
- Primary account number, expiry, and verification value. These never belong in a Solana account or in an MXE input that can be logged.
- A card token from the issuer, used as the private destination handle.
- The authorization amount, which the issuer sees in the clear even when the chain does not.
The preview collects none of those fields. There is no card form on the desk.
Preview limit
A local send, documented on Sealed transfers, is the closest preview behavior: it debits a sealed balance and writes a queued activity row. It does not pretend the destination is a card.