Karak
Karak links supported collateral to operator vaults, with DSS exposure, cost inputs and exit states varying by route.
Karak connects supported collateral with operator vaults that can secure Distributed Secure Services. Depositors receive vault shares, and their collateral follows that route’s operator, DSS and withdrawal terms until redemption finishes. Review the asset’s path through wallet approval, deposit, delegation, DSS exposure, withdrawal and final balance reconciliation.
Table of contents
Route Properties Before Any Deposit
Route selection begins with the underlying asset, network, vault implementation and operator address. Those properties identify what the wallet will authorize and where the collateral will move. They also separate a direct token-vault deposit from native restaking or a position managed through an additional wrapper.
The standard token vault uses ERC-4626 share accounting with an asynchronous redemption extension. Custom vault implementations can support different asset handling when they implement the required Karak interface and their implementation is allowlisted. Native restaking uses a separate NativeVault design. Similar screen labels can therefore represent different contracts, accounting paths and exit procedures.
Version is also part of route identity. V1 and V2 vault shares are not automatically interchangeable, and migration is a contract action rather than a display setting. The documented migration path depends on an allowlisted route between vaults that use the same underlying asset. Its output is a new share balance that should be checked separately from the old balance.
Shares, Operators and Delegation
A deposit into a Karak vault mints shares and implicitly delegates the underlying collateral to the operator attached to that vault. The shares measure a proportional claim rather than a fixed promise of one underlying unit. Their asset value follows the vault conversion rate, which can reflect rewards, losses or slashing.
Operators choose which DSSs they serve and which vaults they allocate to each service. One vault can secure more than one DSS, so a single share position may inherit several sets of operational duties. That reuse can expand reward opportunities, but it also broadens the events that may place collateral at risk.
Choosing a different asset does not by itself remove operator exposure. A different operator means selecting a vault configured for that operator and reviewing its DSS registrations again.
How Does a Deposit Become Shared Security?
A Karak deposit becomes shared security when its operator registers the vault with a Distributed Secure Service. Karak Core records the allocation and exposes the functions used for stake updates and slashing requests. The operator performs the service’s work, while the depositor’s exposure follows the vault rather than a personal choice of individual tasks.
Compatibility Before Return
Compatibility determines whether a route is executable before any projected reward matters. The connected network, asset contract and selected vault must describe the same deployment.
Asset symbols are not sufficient identifiers across networks. Match the token contract and decimals with the underlying asset configured in the vault, then confirm that the wallet is connected to the vault’s chain. The account also needs that chain’s gas asset for the approval, deposit and later exit transactions.
Path class changes the checks. A standard token vault accepts its configured ERC-20 and issues shares. Native restaking follows validator and node accounting through NativeVault. A liquid restaking wrapper may add its own receipt token, allocation policy, administrator controls and withdrawal queue above the underlying Karak positions.
A required swap, bridge or wrapper is a separate dependency, not an invisible part of the deposit. Each added dependency can introduce another transaction, cost input and failure boundary. If direct compatibility is the priority, a route that accepts the held asset on its present network has fewer state transitions to reconcile.
Cost Inputs and Reward Conditions
Route cost comes from transactions and conversions rather than one protocol-wide fee. A token-vault path can require an ERC-20 approval, a deposit, a withdrawal request and a finishing transaction. Network gas changes with traffic. A route that first swaps, bridges or enters a wrapper adds the fees and price impact of those actions.
Reward terms also vary by route. Karak Core does not impose one yield for every vault, and DSS reward distribution sits outside the core accounting path. The operator, service or wrapper may set separate eligibility and claim rules. A displayed rate, points multiplier or campaign label should therefore be tied to its asset, vault, DSS and time window before it influences a choice.
Estimate each state transition separately. The relevant total combines gas units and gas price for every required transaction, plus any conversion or bridge cost. A pre-existing allowance can remove one approval transaction, while a wrapper can add another claim or queue transaction.
Slashing Scope and Failure Domains
Slashing exposure follows operator behavior and the DSSs backed by the vault. A DSS can request a penalty for an operator that violates its service rules.
The request is not the same state as a completed slash. Karak routes a request through its slashing process, and the veto committee can cancel it before finalization. Once a valid slash is finalized, the affected vault loses assets. Depositor shares then represent a claim on the reduced pool.
Other risks sit outside DSS enforcement. A deposited token can lose market value or diverge from the asset it is intended to track. Smart-contract faults, wrapper administration and bridges can add separate loss paths. Multiple DSS registrations concentrate those service-specific exposures on the same vault balance rather than diversifying the underlying claim.
Withdrawal States and Exit Timing
Exiting a standard token vault is a request-and-finish process, not a synchronous ERC-4626 withdrawal. The first transaction starts redemption by committing shares and a beneficiary.
The documented V2 default ERC-20 vault uses a nine-day minimum between starting and finishing redemption. The delay leaves time for the protocol’s slashing process to address conduct that occurred before the exit request. Other vault implementations or wrappers can impose different queues, so their live terms need a separate reading.
A successful start emits a withdrawal key and records the share amount, beneficiary and start time. Pending status can be checked from the vault’s withdrawal data. The wallet has not received the underlying asset at this point, even if an interface describes the request as submitted or unstaked.
After the delay matures, the finishing transaction burns the committed shares and sends the claimable assets to the beneficiary. Reconcile the event’s claimed amount with the token balance received. Slashing or a changing share-to-asset ratio can make the final asset amount differ from an earlier preview.
A Compatibility-First Route Test
Consider a hypothetical comparison of two Karak token-vault routes for a holder who wants predictable inputs. Every changing input is hypothetical: network, held asset, vault, operator, DSS set, conversion requirement, gas quote, reward display and exit status.
The comparison starts with one question: can each vault accept the held asset on the wallet’s current network? Route A does. Route B requires both a conversion and a bridge. The same dimensions are then recorded for each route: vault asset, operator, DSS registrations, approval and deposit transactions, exit transactions and redemption delay.
Route B displays a larger conditional reward, but that benefit relies on extra contracts and variable conversion costs. Route A has the simpler cost relationship: approval gas plus deposit gas plus request gas plus finish gas. Route B adds swap price impact, swap gas, bridge fees and bridge execution risk. No fixed total is assumed because each input changes at execution.
The holder selects Route A, checks the expected shares and sets a minimum acceptable share output before signing. After confirmation, the holder records the deposit event. The resulting share balance is the observable entry result. On exit, the request remains pending until the delay expires; the finishing transaction then sends the underlying asset to the beneficiary. The route meets the holder’s constraint when that same compatible asset returns and the claimed amount reconciles with the final balance.
Transaction Evidence and Reconciliation
Transaction evidence separates an interface message from an executed state change. Before signing, the chain ID, vault address, underlying token and beneficiary should match the intended route. After confirmation, the receipt and vault events show whether assets entered, how many shares were minted and which address received them.
Exit reconciliation uses the same discipline in reverse. The start event identifies committed shares and the withdrawal key, while the pending record shows whether the request remains queued. The finish transaction’s events show the shares burned and assets claimed. If an interface lags, those contract records distinguish a display delay from a failed or incomplete transaction.
Balance changes close the accounting loop. The entry side should pair an underlying-token decrease with a vault-share increase. The exit side should pair a share reduction with an underlying-token increase at the named beneficiary. Unexpected differences call for reviewing the transaction logs before submitting another action.
Maintenance Across an Open Position
Open positions need periodic review because operator allocations and reward conditions can change. The original deposit receipt proves entry, but it does not freeze later DSS exposure.
Vault status, pause state, operator identity and current DSS registrations describe the live security path. The share-to-asset conversion shows the claim represented by the position. Where a wrapper sits above Karak, its allocation and withdrawal records must also reconcile with the underlying vault shares.
Wallet permissions deserve a separate check. A deposit approval authorizes token movement up to its allowance, while ownership of minted shares does not require that allowance to remain open. An allowance larger than the intended deposit can be reduced after the transaction without altering the existing vault position.
Keep the vault address, deposit receipt, share balance, withdrawal key, beneficiary and finish receipt together. A completed exit ends with the underlying asset in the beneficiary balance and the corresponding shares removed. If either side is missing, the route has not reached a reconciled final state.
FAQ
Can Any ERC-20 Token Be Deposited Into a Karak Vault?
No. A standard vault accepts the single underlying asset configured for that deployment. The token contract, network and vault address must match, because the same symbol on another chain does not establish compatibility. An operator can support several assets through separate vaults, but one vault address does not become a universal deposit endpoint.
Is an ERC-20 Approval Already a Karak Deposit?
No. Approval only gives the selected vault permission to transfer a defined token amount from the wallet. The separate deposit transaction moves the underlying asset and mints vault shares to the chosen recipient. If approval succeeds but no deposit event or new share balance appears, the wallet has not entered the vault.
Does Bridging an Asset Create a Karak Vault Position Automatically?
No. A bridge transfers value to another network, while a vault deposit creates the restaking position. After bridging, the asset still must match a supported vault on the destination network. A confirmed deposit event and a minted share balance are the evidence that the Karak position exists.
Does One Vault Share Always Redeem for One Underlying Token?
No. Vault shares represent a proportional claim on pooled assets rather than a fixed one-for-one promise. The vault’s share-to-asset conversion determines the claim at a given state. Rewards, losses, rounding and finalized slashing can affect that relationship, so the share balance alone does not state the final asset amount.
Can Existing Vault Shares Be Switched to Another Karak Operator?
Not inside the same operator-linked vault. The operator is part of that vault’s configuration, so its shares continue to represent the original vault claim. Moving to another operator generally requires an exit from the first vault and a separate deposit into a vault attached to the new operator, unless a wrapper performs those actions under its own rules.
Are All V1 Shares Eligible for Migration Into Any V2 Vault?
No. The documented migration path requires an allowlisted route and the same underlying asset in both vaults. It redeems the old position, deposits the assets into the approved V2 vault and mints new shares. Tokenized V1 shares may first need to return to the legacy supervisor’s internal accounting before migration can proceed.
Is Native Restaking the Same as Depositing an ERC-20 Into a Standard Vault?
No. Native restaking uses the NativeVault design and tracks validator and node-related state. A standard token vault accepts its configured ERC-20 and uses share accounting for deposits and asynchronous redemptions. Both can connect collateral to an operator, but their prerequisites, state evidence and exit mechanics are different.