> For the complete documentation index, see [llms.txt](https://docs.pokefi.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pokefi.xyz/core-concepts/custody-and-vaulting.md). # Custody and Title Tokens This is the hardest and most important part of PokeFi. A loan is only as safe as the guarantee that the collateral behind the token actually exists, is authentic, and is recoverable. The custody bridge connects a physical graded card to an on-chain title token, so that lending against it is backed by a real asset rather than a promise. *** ## The Problem It Solves A purely on-chain collectible is only worth what someone will pay for the token. A vaulted physical card is worth what the card itself sells for, redeemable by whoever holds legal title. PokeFi lends against the second kind of asset. For that to be safe, every title token must map to a specific, authenticated, insured card sitting in a vault, and the holder of the token must have enforceable ownership of that card. *** ## The Vault Model PokeFi uses a professional custody partner for beta rather than standing up its own vault on day one. This de-risks custody, insurance, and legal title, which are the parts most likely to sink a young real-world-asset product, and lets engineering focus on the lending protocol. Owning custody becomes a later-stage moat, not a launch requirement. The bridge has four stages. ### 1. Intake and Authentication Cards must arrive already graded by a recognized authority: PSA, BGS, CGC, or SGC. On arrival, the card is: * Verified against the grader's **certificate number** and its entry in the **population report** * Photographed in high resolution, front and back * Assigned a unique identifier within PokeFi Cards that cannot be verified against a grader's record are rejected. Counterfeit-slab detection is an explicit part of intake. ### 2. Custody The physical card is held in a professional, insured, climate-controlled vault: 24/7 monitored, fine-art-grade security, fully insured while vaulted. The card stays there for as long as it is tokenized, whether or not it is currently backing a loan. ### 3. Tokenization A **title token** is minted on Solana representing legal ownership of that specific physical card. Its metadata links to: * The grader and certificate number * The card name, set, number, edition, and grade * The population count at that grade * High-resolution photos * The vault reference The title token is minted only by the authorized custody authority. It is the on-chain object that moves into escrow when the card backs a loan. ### 4. Redemption The token holder can redeem the physical card at any time it is **not** actively escrowed against a loan. Redemption ships the card to the holder and burns the token. While a card is escrowed against a live loan, it cannot be redeemed, which is what makes it usable as collateral. *** ## Card Status Every vaulted card has a status that reflects where it is in this lifecycle: | Status | Meaning | | ---------------- | -------------------------------------------------------------- | | `vaulted` | Held in the vault, tokenized, not currently backing a loan | | `escrowed` | Backing a live loan; the title token is held in program escrow | | `redeemed` | Shipped back to the owner; the title token has been burned | | `in_liquidation` | Being sold through the liquidation channel after a default | A card must be `vaulted` to back a new loan, and it can only back one live loan at a time. *** ## The Title Token in a Loan When a borrower requests a loan, the card's title token moves from the borrower's control into a program-controlled **escrow**, a Solana program-derived address. During the loan: * The borrower cannot sell, move, or redeem the card. * The lender cannot touch the card unless the loan defaults. * Only the program can move the token, and only according to loan state. On repayment, the escrow releases the token back to the borrower. On default, it transfers the token to the lender. See [How a Loan Works](/core-concepts/loan-lifecycle.md). For the on-chain mechanics of the token itself, see [The Title Token](/technical-reference/title-tokens.md). *** ## Legal Title The token must confer real, enforceable ownership of the physical card, not just a marker in a database. In the United States this involves secured-transaction considerations under UCC Article 9 and Article 12, and the mechanism by which a default transfers legal ownership to the lender is a legal workstream, not only a smart-contract one. PokeFi treats enforceable title, and a clean default-transfer path, as a prerequisite that is settled with counsel before collateral is accepted. *** ## Proof of Reserve Because trust in the collateral is the foundation of the whole product, PokeFi publishes attestations that each title token maps to a real, vaulted, authenticated card. "Don't trust, verify" is a feature: the public explorer links each loan to its collateral card, its grader certificate, and its vault reference, so anyone can trace the chain from an on-chain loan back to a specific physical object. *** ## Related * [Vaulting a Card](/guides/vaulting-a-card.md): the step-by-step guide to getting a card into the vault * [The Title Token](/technical-reference/title-tokens.md): the on-chain representation of a vaulted card * [Security](/reference/security.md): custody, insurance, and the platform's risk disclosures --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.pokefi.xyz/core-concepts/custody-and-vaulting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.