Skip to content
YARDWATCHCHAIN PULSE

ABOUT

What is TickerYard?

A project for moving assets between blockchains, with YARD and Yardkeepers as a separate token-and-NFT part of its ecosystem.

Start with the beginner guide →

What the project offers today

Moving an asset to another blockchain involves more than sending it to an address. The destination may use a different token contract, and a bridge must account for what backs it. TickerYard provides an interface for supported routes to and from Robinhood Chain.

yBTC

A receipt for WBTC held in a vault on Arbitrum One. The documented bridge moves between that WBTC and yBTC on Robinhood Chain. It does not accept native Bitcoin.

Source: yBTC guide ↗.

CROP

A compatible token can have its own route to Robinhood Chain. Deposits on the origin network back the representation received on the destination. A route does not automatically create a trading market.

Source: CROP guide ↗.

YARD & Yardkeepers

YARD is a fungible token. Yardkeepers is a collection of 3,333 NFTs. The external Anvil market handles NFT trading, activation and tier upgrades; these are different actions from bridging.

Source: YARD guide ↗.

The official documentation describes yBTC and CROP as released. Availability still depends on the exact asset, route and current app checks. Reviewed 20 September 2026; this page is not a live service-status feed.

The white paper, in simple words

The long-term idea is to let you describe the result you want: “Move this exact asset from this network to that network.” TickerYard would identify acceptable paths, compare them and show what each path costs and relies on.

You can think of the proposed role as an orchestrator: it coordinates the journey, while bridges, exchanges and messaging systems carry out particular steps. This is an explanation of the design, not a claim that every asset or network is supported.

  1. Preserve your intent. A token with the same name is not necessarily the asset you requested. The design checks the network, contract, recipient and allowed representation.
  2. Compare eligible routes. First reject paths that fail the rules, then compare the remaining choices. The lowest fee alone is not enough: the amount received, timing and dependencies matter too.
  3. Track the whole journey. A successful source transaction does not prove that the destination delivery has finished. The design includes monitoring and recovery states.
  4. Add controlled representations where appropriate. The proposed broader asset network uses vaults, registries and accounting so that issued tokens and pending claims remain covered by backing.
How is this different from a bridge?

A bridge is one transport mechanism. The white paper proposes a layer that can select and validate paths through existing providers, plus its own asset rails when appropriate. Chainlink CCIP is a messaging dependency in the reference design; using it does not remove risks in TickerYard’s own contracts or custody rules. The paper also discusses LayerZero, Unit and bridge aggregators as related approaches, not endorsements or confirmed integrations.

What about tokenized shares?

The paper explores certificate mirrors and fungible wrappers as a demanding first use case. A remote representation would depend on the underlying asset, issuer rules and a valid return path. This was a reference integration in the paper, not evidence that anyone can freely bridge any share or acquire direct registered shareholder rights.

Source: archived design paper, §§1–4 and 6–11. Read the referenced PDF ↗

The proposed role of future Keeper operators

The paper describes a separate participation network: a protocol defines a small, permitted task; a local runner performs it; an objective receipt proves completion. A future client would have to authorize its own adapter and fund the job. Owning an NFT alone would not give permission to act for every protocol.

Would an Anvil Lord automatically get paid jobs?

No. In this design, current-owner Tier 4 is only an eligibility condition. A separate enrollment binds a local runner, and each client sets qualification and assignment rules. The first proposed TickerYard canary has no work reward. Funded production jobs, operational history and any bonds are later steps—not benefits you should assume when buying or upgrading today.

What kinds of work does the paper imagine?

Examples include completing a cross-chain action, triggering a permitted recurring operation, checking a sponsored milestone, watching for a defined accounting problem, or performing a bounded treasury task. These are proposed service categories. They are not a list of available jobs or confirmed partners.

Where would future payments come from?

The design separates job payments funded by clients from Anvil rewards and from a possible later TickerYard revenue-distribution program. Revenue sharing would require positive distributable revenue, reserves, exact funding and separate release gates. Activation, trading volume and token appreciation are not substitutes for paying customers.

Source: archived design paper, §§5 and 12–14. The current holder guide ↗ does not establish a live operator-job entitlement.

Which document are we referencing?

Asset Mobility and Protocol Participation, cover version v1.1, prepared 9 August 2026, author @jeronxd3. The supplied filename says “v1-3”; the version above follows the document’s cover. This archived design candidate predates the current product guides.

Use it to understand the ambition and architecture. Use the current documentation and app for available actions and terms. For example, the paper’s pre-launch status and historical royalty figures must not be read as current deployment facts.

Archived design paper · PDF ↗Current official documentation ↗

Where YardWatch fits

YardWatch is an independent dashboard for following YARD, Yardkeepers, wallet activity and upgrade estimates. It is not TickerYard or Anvil, and it does not execute purchases, claims or upgrades. This guide is an independent explanation, not an official endorsement.