Integrate Titan Locker Into Your Contracts & dApp

You can integrate Titan Locker directly from your own contracts or dApp on Robinhood Chain (chain ID 4663). Approve your token to the TitanLockerManagerV2 contract, then call createTokenLock or createVestingLock; the manager deploys an isolated lock contract and emits an event with the new lock id. Everything is readable on-chain, so integrators can verify locks without an API.

Addresses (Robinhood Chain, 4663)

Create a token lock

Approve the token to the manager, then call createTokenLock(token, amount, unlockTime). Pass the flat ETH fee as msg.value, or send 0 to pay the fee in-kind from the token.

// Solidity — lock tokens from your own contract
interface ITitanLockerManagerV2 {
    function createTokenLock(address token, uint256 amount, uint40 unlockTime) external payable;
    function ethFee() external view returns (uint256);
}

IERC20(token).approve(MANAGER_V2, amount);
uint256 fee = ITitanLockerManagerV2(MANAGER_V2).ethFee();
ITitanLockerManagerV2(MANAGER_V2).createTokenLock{value: fee}(token, amount, unlockTime);

Create a vesting lock

Call createVestingLock(token, amount, start, cliff, end) with start < end and start <= cliff <= end. The grant releases linearly to the lock owner via release().

ITitanLockerManagerV2(MANAGER_V2).createVestingLock{value: fee}(
    token, amount, start, cliff, end
);

Read a lock from a dApp (viem)

import { createPublicClient, http } from "viem";

const client = createPublicClient({
  chain: { id: 4663, name: "Robinhood Chain", nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 }, rpcUrls: { default: { http: ["https://rpc.mainnet.chain.robinhood.com"] } } },
  transport: http(),
});

const count = await client.readContract({
  address: "0x26b0654a0756dcd036d4e7215324f3d2be34d79e",
  abi: managerV2Abi,
  functionName: "tokenLockerCount",
});

There are two managers - check both

New locks are created on TitanLockerManagerV2, but the original TitanLockerManagerV1 is still deployed and holds every lock created before V2 shipped. Any integration that only reads V2 will silently miss legitimate, still-active V1 locks. Always query both manager addresses and merge the results, exactly as Titan Locker's own frontend does.

Look up every lock for a token, LP pair, or wallet

Both managers index every lock by every address that matters to it - the locked token (or, for a Uniswap V3/V4 position, its position manager), the lock's own contract address, the lock owner, and for LP/position locks, the pair's underlying token0/token1. Calling getTokenLockersForAddress(address) on either manager returns every lock id touching that address, with no separate indexer required.

interface ITitanLockerManager {
    function getTokenLockersForAddress(address addr) external view returns (uint40[] memory);
    function getTokenLockData(uint40 id) external view returns (
        bool isLpToken, uint40 id, address contractAddress, address lockOwner,
        address token, address createdBy, uint40 createdAt, uint40 unlockTime,
        uint256 balance, uint256 totalSupply
    ); // V1 shape - V2's getTokenLockData additionally reports LockKind and tokenId; see the ABI.
}

const [v1Ids, v2Ids] = await Promise.all([
  client.readContract({ address: "0x713E56CeE7060F01F710bF26Aff988264dcfb311", abi: managerV1Abi, functionName: "getTokenLockersForAddress", args: [tokenAddress] }),
  client.readContract({ address: "0x26b0654a0756dcd036d4e7215324f3d2be34d79e", abi: managerV2Abi, functionName: "getTokenLockersForAddress", args: [tokenAddress] }),
]);

const locks = await Promise.all([
  ...v1Ids.map((id) => client.readContract({ address: "0x713E56CeE7060F01F710bF26Aff988264dcfb311", abi: managerV1Abi, functionName: "getTokenLockData", args: [id] })),
  ...v2Ids.map((id) => client.readContract({ address: "0x26b0654a0756dcd036d4e7215324f3d2be34d79e", abi: managerV2Abi, functionName: "getTokenLockData", args: [id] })),
]);

Calculating a percentage of supply locked (fungible locks only)

For a plain ERC-20 or LP token lock, sum the balance field across every matching lock for that token, then divide by IERC20(token).totalSupply(). This is meaningful only for fungible balance-based locks - a Uniswap V3/V4 position lock holds an NFT, not a token quantity, so it has no balance to include in this calculation and no valid "percentage locked" figure. Don't combine position locks into a token-supply percentage; state their lock status separately.

How explorers can verify and display a Titan Locker lock

A block explorer already has everything needed to show "this address is a Titan Locker lock": each lock contract is deployed by one of the two manager addresses above, and its own getLockData()/getTokenLockData() view function (available on the lock contract itself, not just the manager) returns its kind, owner, asset, and unlock time with no extra lookups. Cross-reference the deploying manager to confirm it's a genuine Titan Locker child contract rather than an unrelated contract with a similarly-named function.

How wallets can show lock status for a held token or position

A wallet already knows the tokens and NFTs an address holds. To additionally flag "this token has locks" or "this position is locked," call getTokenLockersForAddress on both managers with the token's (or position manager's) address - a non-empty result means locks exist for that asset, and getTokenLockData on each id gives the amount, owner, and unlock time to display inline.

How analytics platforms can display lock status

The same getTokenLockersForAddress + getTokenLockData pattern above is exactly what an analytics platform needs to show a project's locked supply, upcoming unlock dates, or vesting schedule progress (via getVesting() and vestedAmount() on a vesting lock's own contract) - all without needing to run any Titan Locker-specific infrastructure, just an RPC connection to Robinhood Chain.

How exchanges can verify locked liquidity before listing

Apply the same token-address lookup to the LP token (or, for a Uniswap V3/V4 pool, to the position manager plus the pool's real underlying tokens) a project claims to have locked. Confirm the reported balance and unlock time directly from getTokenLockData rather than trusting a submitted screenshot or link - the on-chain data is the actual lock, not a claim about one.

Displaying a lock badge or certificate

The simplest integration is linking directly to the lock's own certificate page - https://titandeployer.com/lock/{id} for a V1 lock, https://titandeployer.com/lock/v2/{id} for a V2 lock - which already reads and displays everything above without any integration work at all. Each certificate also has a public, unauthenticated PNG at its own /opengraph-image path (for example https://titandeployer.com/lock/v2/13/opengraph-image) showing the same data as an image, embeddable directly with a plain <img> tag for a live-updating lock badge.

Security considerations for integrators

• Always verify which manager (V1 or V2) deployed a lock contract before trusting its data - don't assume every lock is on V2.
• A lock contract's own address is the source of truth; don't reconstruct or guess a lock's address instead of reading it from getTokenLockAddress/getTokenLockData.
• Treat a Uniswap V3/V4 position lock's balance as always zero and meaningless - check kind first, and read the position's underlying pair via the lock's own getUnderlyingTokens() rather than assuming it holds an ERC-20 balance.
• Confirm the lock contract's source is verified on Blockscout before trusting a value-moving integration (e.g. a listing decision) that depends on it.