HourTab

Blog › ICP guides

Blockchain developer on retainer: tracking smart contract advisory and demonstrating Web3 development value between mainnet deployments and quarterly protocol reviews

July 22, 2026 · ~19 min read

The mainnet deployment and the quarterly protocol review are the visible blockchain development events. When a founder presents the protocol architecture to investors, when a technical lead reviews the quarterly tokenomics report with the board, when a DeFi team shares the audit results with the community — those are the artifacts on the table: the mainnet deployment of the staking contract that successfully launched with $4.2M TVL in the first 72 hours, the quarterly protocol review that showed 94% of audit findings resolved with three medium findings deferred to v2, the tokenomics report that showed the circulating supply was tracking within 3% of the modeled schedule. What none of those artifacts shows is the continuous smart contract governance between those visible milestones, or whether that ongoing advisory identified the reentrancy vulnerability in the withdrawal function before the external audit flagged it, optimized the batch claim function gas costs to stay within the block gas limit as the token holder count grew, and designed the vesting cliff schedule that prevented a single unlock event from releasing 23% of circulating supply during a low-liquidity period.

The smart contract security review that identified that the withdrawal function in the escrow contract checked the user’s balance after the external call rather than before it — where the function called the recipient’s receive() function via address.call{value: amount}("") and then zeroed the sender’s balance with balances[msg.sender] = 0 — where a malicious contract at the recipient address could implement a receive() function that called the escrow contract’s withdraw function again before the first call’s state update had executed, re-entering the withdrawal function with the sender’s balance still showing the original amount and withdrawing it again in a recursive loop until the gas stipend was exhausted or the contract balance was drained — where the vulnerability would not have been detected by the functional test suite because the test used an EOA recipient address rather than a contract address with a re-entrant receive() function — that identified the reentrancy pattern three weeks before the external audit, enabling the checks-effects-interactions rewrite and the ReentrancyGuard modifier to be deployed on testnet and validated before the external audit began.

The gas optimization advisory that identified that the batch claim function in the token airdrop contract was iterating over an address array and performing a cold SLOAD for each recipient’s eligibility record at 2,100 gas per cold storage access — where the initial deployment had 8,000 token holders and the batch claim cost 16.8M gas per transaction (within the 30M block gas limit), but the holder count was projected to reach 120,000 by the end of the year, at which point a batch claim covering all holders would require 252M gas far exceeding the block gas limit and making the function uncallable in a single transaction — where the fix required restructuring the eligibility verification from an on-chain storage lookup to a Merkle proof validation where each claimant provides their own inclusion proof in an individual claim transaction, reducing the gas cost from O(n) storage accesses to O(log n) hash operations per claim and eliminating the batch size constraint entirely — that redesigned the eligibility verification before the holder count exceeded the block gas limit rather than after the batch claim function became uncallable in production.

The tokenomics design advisory that identified that the vesting schedule for the strategic investor allocation had a twelve-month cliff unlock event that would release 15 million tokens representing 23% of the projected circulating supply on a single day — where the average 30-day trading volume was $180,000 and the cliff unlock would make $2.1M of tokens available for liquidation in a single block — where the twelve-month cliff had been designed to align with the product launch milestone without modeling the supply impact against the liquidity profile at the expected point of unlock — that redesigned the cliff structure to a six-month cliff followed by a linear twenty-four month vest, distributing the supply release over time and capping the monthly unlock at 2.5% of circulating supply rather than releasing 23% on a single day.

Blockchain developers and smart contract consultants on monthly retainer do their most consequential work in the continuous stretches between mainnet deployments and quarterly protocol reviews: the smart contract security governance that reviews contract code against the reentrancy, integer overflow, access control, oracle manipulation, and front-running vulnerability patterns before each deployment rather than after an exploit drains the treasury; the gas optimization advisory that validates that contract functions remain within the block gas limit as the protocol scales and that gas costs remain competitive with alternative implementations as the user base grows; the tokenomics governance that models the supply and demand dynamics of upcoming cliff unlock events, emission rate changes, and staking reward adjustments against the current liquidity profile before those events execute on-chain and cannot be reversed; the wallet integration advisory that ensures the web3 frontend correctly handles the nonce lifecycle, session expiry, multi-signature coordination, and hardware wallet compatibility edge cases that produce user-facing errors on the paths that occur too rarely to appear in the test suite; and the DeFi protocol design advisory that validates the economic invariants, fee parameter choices, and MEV exposure of proposed protocol mechanics before they are deployed to mainnet where economic attacks can drain liquidity pools or destabilize peg mechanisms. All of that advisory is invisible to the founder and technical leadership without a work log that connects the ongoing smart contract governance to the protocol health and absence of exploit events it enables.

What makes smart contract advisory categorically different from conventional software advisory

Smart contract advisory is categorically different from conventional software advisory in three properties that define the risk profile and the advisory approach required. Understanding these properties is necessary to understand why the ongoing retainer function — continuous pre-deployment review rather than post-deployment debugging — is structured differently from a conventional software advisory engagement.

Immutability after deployment. A deployed smart contract’s bytecode is immutable on the blockchain. Unlike a web application where a discovered vulnerability is patched with a server-side update that takes effect immediately, a vulnerability in a deployed smart contract without an upgrade mechanism is permanent: it cannot be fixed without migrating to a new contract address and convincing all token holders, liquidity providers, and protocol users to migrate their assets. Contracts that use the proxy upgrade pattern (EIP-1967 transparent proxy or UUPS) can have their implementation logic updated, but the upgrade mechanism itself must be governed with a timelock and multi-signature requirement that introduces its own complexity and attack surface. The architectural consequence for advisory is that security review must be performed before deployment to testnet and mainnet, not after, because post-deployment remediation is orders of magnitude more expensive and disruptive than pre-deployment review.

Irreversibility of on-chain transactions. When a smart contract vulnerability is exploited, the attacker’s transactions are included in the blockchain and cannot be reversed by any party, including the contract owner. Unlike a web application breach where stolen credentials can be invalidated, access tokens can be revoked, and unauthorized database writes can be rolled back, stolen tokens and ETH cannot be recovered after the transaction confirms. The blockchain provides a complete, auditable record of the exploit in every detail, but that record is immutable. The architectural consequence for advisory is that preventing exploitation is the only viable strategy; incident response that recovers stolen funds is not available except in the rare case of coordinated ecosystem intervention (e.g., the Ethereum classic/DAO fork, which was an exceptional event and not a recoverable mechanism).

Full transparency of contract code and state. Smart contract bytecode, storage state, and all historical transactions are publicly visible to anyone via the blockchain explorer. A contract deployed to Ethereum mainnet is visible to every developer in the world, including the developers who specialize in identifying and exploiting vulnerabilities. Contracts are often decompiled and their Solidity source reconstructed; verified source code published to Etherscan makes the security review even easier for potential attackers. The architectural consequence for advisory is that security review must assume a sophisticated adversary with full knowledge of the contract code and unlimited time to analyze it, which is the standard assumption in formal security analysis and very different from the assumption in conventional application security where the attacker has black-box access to the application.

What ongoing blockchain developer retainer advisory actually consists of

Smart contract security review advisory

Smart contract security review is the highest-value function in a blockchain developer retainer because it is the only mechanism that prevents vulnerability classes from reaching deployed contracts, and deployed vulnerabilities in contracts holding significant value have a long history of producing large, irreversible losses. The most consequential vulnerability classes are well-documented and follow consistent patterns, making them systematically reviewable, but their presence in deployed contracts demonstrates that systematic review is not universally performed before deployment.

Reentrancy vulnerability review confirms that the contract follows the checks-effects-interactions pattern in all functions that make external calls: the checks (balance verification, permission validation) must execute first, then the effects (state variable updates that record the transaction outcome), and then the external interactions (token transfers, ETH sends, external contract calls) last. Any function that performs an external call before updating the state variables that guard against re-entry creates a window for a malicious contract to re-enter the function before the state update executes. The ReentrancyGuard modifier from OpenZeppelin provides defense in depth but does not substitute for correct checks-effects-interactions ordering, because the modifier adds gas cost on every function entry and should accompany correct state management rather than replace it.

Integer arithmetic review confirms that all arithmetic operations in Solidity 0.7.x and below use SafeMath for addition, subtraction, multiplication, and division on user-controlled values; Solidity 0.8.x provides checked arithmetic by default and reverts on overflow or underflow, but contracts that use unchecked blocks for gas optimization must be reviewed to confirm that no user-controlled value is used in unchecked arithmetic where overflow or underflow is possible. Division operations require particular review because Solidity integer division truncates toward zero rather than rounding, which can produce unexpectedly small results in fee calculations, reward distributions, and proportional share calculations.

Access control review confirms that all privileged functions — functions that can pause the contract, upgrade the implementation, change fee parameters, or withdraw protocol fees — are protected by the appropriate access control modifier (onlyOwner for single-owner contracts, role-based access control via OpenZeppelin’s AccessControl for contracts with multiple privilege levels) and that the ownership transfer and role assignment mechanisms cannot be called by unauthorized parties.

On retainer: reviewing all new contract functions and all modified contract functions against the reentrancy, integer arithmetic, and access control patterns before they are deployed to testnet; reviewing the upgrade mechanism implementation for proxy contracts to confirm that the initialize function is protected against re-initialization; and advising on the formal verification scope for functions managing significant TVL that warrant automated symbolic execution verification in addition to code review.

Gas optimization advisory

Gas cost is a user experience and scalability constraint in Ethereum smart contract development with no direct analogue in conventional software development. Every computation executed by the EVM has a gas cost defined by the Ethereum Yellow Paper; users pay the gas cost of their transactions as a fee to the network, and the block gas limit caps the total computation that can be included in a single block. A smart contract function with a gas cost that grows linearly with the number of token holders or liquidity providers becomes uncallable as the protocol scales, and the gas cost of user-facing operations directly affects the economic viability of the protocol at the current gas price environment.

Gas optimization advisory on retainer covers the storage access pattern review that identifies the most expensive gas operations and advises on designs that reduce their frequency: cold SLOAD operations (accessing a storage slot for the first time in a transaction) cost 2,100 gas under EIP-2929; warm SLOAD operations (accessing a previously-accessed slot in the same transaction) cost 100 gas; caching storage variables in memory at the start of a function and using the in-memory copy for all subsequent reads within the function reduces multiple cold SLOADs to one cold SLOAD and multiple in-memory reads at 3 gas each. Storage slot packing review identifies struct fields and state variables that can be packed into the same 32-byte storage slot to reduce the number of storage slots required and the corresponding SSTORE costs. Calldata versus memory parameter passing review identifies external function parameters that can be declared calldata rather than memory, reducing gas costs for read-only array and struct parameters because calldata does not require copying the parameter to the EVM memory space.

On retainer: reviewing the gas report from the Hardhat or Foundry test suite for all new functions and modified functions before they are deployed to testnet; advising on gas optimization for functions that are called frequently by users (swap, claim, stake, unstake) where high gas costs directly affect protocol competitiveness; identifying functions approaching the block gas limit at current usage parameters and recommending redesigns before the user count growth makes them uncallable; and reviewing the gas implications of EIP upgrades that change opcode costs (EIP-2929, EIP-3529) for contracts that were optimized under prior gas cost assumptions.

Tokenomics design consultation

Tokenomics design governs the economic model of the protocol token: the supply schedule that determines how many tokens exist at each point in the protocol’s lifecycle, the distribution mechanics that determine how tokens are allocated across founders, investors, team, ecosystem development, and public distribution, the vesting and cliff structures that govern when allocated tokens become liquid, the inflation and deflation mechanisms that determine whether the circulating supply grows or shrinks over time, and the incentive design that determines whether the token distribution creates the behavioral incentives the protocol needs to achieve its network effects.

Tokenomics consultation on retainer covers the supply schedule modeling that projects the circulating supply at each point in time against the vesting and emission schedules, identifies cliff events where a significant proportion of supply becomes liquid in a short window, and models the market impact of those events against the historical trading volume and on-chain liquidity; the emission rate calibration for staking rewards and liquidity mining programs that balances the incentive value of the reward against the dilution impact of the emission on existing holders; the governance token design for DAO voting structures that evaluates whether the token distribution produces the voting power concentration that the governance design requires, the minimum quorum threshold that is achievable given the token distribution, and the delegation mechanism that allows passive holders to assign their voting power to active governance participants; and the treasury management architecture that governs how protocol fees are collected, stored, and deployed for protocol development, liquidity support, or buyback-and-burn mechanisms.

On retainer: reviewing cliff and linear vest schedules for new allocation tranches to model the supply impact against the current and projected liquidity; advising on emission rate adjustments for staking and liquidity mining programs when the current rate is producing insufficient incentive or excessive dilution; reviewing governance parameter proposals (quorum threshold changes, voting period adjustments) before they are executed to confirm the intended governance dynamics; and modeling the buyback-and-burn mechanics against the fee revenue and circulating supply to evaluate the deflationary impact.

Wallet integration advisory

Wallet integration is the user-facing layer of a Web3 application where a large proportion of user experience failures occur. Unlike conventional web applications where session management is handled by the server, Web3 applications handle authentication through wallet signatures that must be verified on-chain or off-chain depending on the authentication model. The wallet integration advisory function governs the implementation correctness of the authentication, signing, and transaction submission flows that connect the web frontend to the smart contract layer.

EIP-4361 Sign-In with Ethereum advisory covers the implementation of the standard wallet authentication flow: the message construction that includes the domain, address, statement, nonce, issued-at timestamp, and expiration timestamp fields specified in the EIP; the nonce lifecycle management that generates a random nonce per session, stores it server-side before the sign-in attempt, and invalidates it after a successful authentication to prevent replay attacks; and the session expiry handling that signs out users whose EIP-4361 session has expired and requires re-authentication rather than silently continuing the session past its expiry.

WalletConnect v2 integration advisory covers the relay URL configuration, the session proposal and approval lifecycle, the event subscription patterns for account change and chain change events that require the frontend to update its displayed network context, and the error handling for wallet rejection, disconnection, and the timeout scenarios that occur when the user does not respond to the mobile wallet approval prompt within the session proposal window.

Multi-signature wallet advisory covers the treasury management architecture for protocols holding significant value in a protocol-controlled wallet: the Gnosis Safe signer threshold design that balances security (higher threshold) against operational availability (lower threshold), the transaction proposal and confirmation lifecycle for time-sensitive operations, and the timelocked execution design for high-value operations where a delay between proposal and execution allows the community to identify and respond to malicious proposals.

On retainer: reviewing EIP-4361 implementation for new authentication flows; advising on WalletConnect v2 integration for new frontend features that require wallet connection; reviewing the multi-signature governance implementation for treasury management and protocol parameter changes; and evaluating ERC-4337 account abstraction integration proposals for protocols considering gasless transactions, session keys, or social recovery features.

DeFi protocol design advisory

DeFi protocols operate in an adversarial environment where sophisticated actors actively model the protocol’s economic mechanisms to identify profitable attack vectors: maximal extractable value (MEV) strategies that exploit transaction ordering to extract value from user transactions, economic attacks that exploit the mathematical properties of AMM invariants or lending protocol collateral ratios, and oracle manipulation attacks that exploit the use of on-chain price feeds that can be manipulated within a single transaction through flash loan borrows.

DeFi protocol design advisory on retainer covers the AMM invariant design review for protocols implementing automated market makers: the constant product (x*y=k) invariant used by Uniswap and its derivatives is well-understood but concentrates liquidity at the current price and provides poor capital efficiency at distant price levels; the concentrated liquidity design of Uniswap v3 provides higher capital efficiency within defined price ranges but introduces tick management complexity and liquidity fragmentation across ranges; the stableswap invariant used by Curve is designed for assets with strong peg assumptions and degrades to unfavorable exchange rates when the peg assumption breaks. The choice of invariant determines the capital efficiency, the sensitivity to price impact at various trade sizes, and the MEV surface of the AMM.

Oracle security advisory covers the risk of price oracle manipulation for protocols that use on-chain price data for collateral valuation, liquidation triggering, or reward calculation: the manipulation attack where a malicious actor uses a flash loan to temporarily move the on-chain price on a low-liquidity DEX, calls the target protocol function that relies on the manipulated price, and repays the flash loan in the same transaction; the time-weighted average price (TWAP) oracle design that uses a time-average price rather than the spot price to make flash loan manipulation more expensive (flash loans must execute within a single block; a TWAP spanning multiple blocks cannot be manipulated in a single transaction); and the Chainlink price feed integration that uses an external oracle network rather than an on-chain DEX price, providing resistance to flash loan manipulation at the cost of latency and centralization.

On retainer: reviewing proposed AMM invariant designs and fee tier structures before implementation; advising on oracle selection and TWAP window configuration for protocols with collateral valuation requirements; reviewing MEV exposure in transaction ordering-sensitive functions and advising on commit-reveal schemes or private mempool integrations where MEV extraction would significantly harm user experience; and reviewing the economic parameter design (liquidation threshold, liquidation bonus, borrow cap) for lending protocols against the historical collateral volatility to evaluate liquidation cascade risk.

The work that most commonly goes unlogged in a blockchain developer retainer

The most consistently underlogged blockchain developer advisory work falls into two patterns: security review sessions that confirmed the contract was secure against the vulnerability patterns reviewed, and advisory sessions that prevented a protocol vulnerability from being introduced rather than detecting one that was already present. Both patterns produce the misimpression that the retainer period was quiet when it contained the continuous smart contract governance that enables the protocol to operate without exploit events.

Smart contract security reviews that confirmed the contract code was secure against the reviewed vulnerability patterns are the canonical underlogging case in blockchain developer retainers. Reviewing the withdrawal function against the reentrancy pattern, confirming it used checks-effects-interactions ordering with the balance zero-out before the external call, confirming the ReentrancyGuard modifier was applied, and confirming no other function in the contract made an unguarded external call with outstanding state — that required the same reentrancy analysis, state ordering review, and modifier presence verification as a review that identified the post-call balance check vulnerability. The protocol team that knows their contract was reviewed and confirmed free of reentrancy vulnerabilities is in a materially different security posture than one that assumed it was secure without the governance review to support it.

Gas profile analysis sessions that confirmed all functions were within acceptable gas cost ranges are consistently underlogged by blockchain developers who conflate “no gas optimization issue found” with “no gas optimization work was performed.” Running the Hardhat gas reporter against the test suite after each new function was added, reviewing the function gas costs against the block gas limit at the projected user count, and confirming that all gas costs were within acceptable range — that required the same gas cost analysis, storage access pattern review, and user count projection as a session that identified the batch claim function’s linear scaling problem. The confirmed-acceptable gas profile is the positive outcome of a gas optimization session; logging only sessions that identify regressions systematically understates the volume of gas governance performed.

Audit preparation sessions that confirmed the codebase was ready for the external security audit are consistently underlogged because the session that reviewed the test coverage report, confirmed all critical paths had complete test coverage, reviewed the NatSpec documentation for completeness, and confirmed the deployment scripts were correctly configured produced no finding list. External security audits are expensive (typically $15,000 to $150,000 for a significant protocol codebase) and their cost is partly a function of the codebase quality the audit team encounters: a codebase with complete test coverage, accurate documentation, and well-structured code requires less audit time to review at the same depth as a codebase with sparse tests and no documentation. The audit preparation advisory that produces a higher-quality codebase for the external audit reduces the audit cost and the likelihood that the audit discovers critical findings that require significant remediation.

Retainer rates for blockchain developers and smart contract consultants

Blockchain developer and smart contract consultant retainer rates vary with the depth of security review expertise, the complexity of the DeFi protocol mechanics in scope, and the regulatory and compliance context of the token issuance:

Advisory-only blockchain developer retainers — security review, gas optimization, tokenomics design, wallet integration advisory, and DeFi protocol design — are typically priced differently from retainers that include implementation work (writing production Solidity code, deploying contracts, managing deployment keys). The advisory function that prevents vulnerabilities through design review is distinct from the implementation function that produces contract artifacts; smart contract implementation is also typically separated from advisory to maintain an appropriate independence between the reviewer and the code author, similar to the separation between external auditors and the code they audit.

Making blockchain developer retainer advisory visible to founders and technical leadership

The central challenge in blockchain developer retainer relationships is that the value of ongoing smart contract governance is structurally invisible to the founder and technical leadership when the advisory is working as intended: the absence of exploit events does not show the reentrancy review that prevented the vulnerability from being deployed; the protocol’s ability to handle growth to 80,000 token holders without hitting the block gas limit does not show the batch claim redesign that moved from a linear storage access pattern to a Merkle proof pattern before the holder count exceeded the original design’s ceiling; the stable token price through the twelve-month cliff does not show the cliff redesign that distributed the supply release over a twenty-four month linear vest.

The work log that connects advisory sessions to specific vulnerability findings, gas optimization outcomes, tokenomics model decisions, and wallet integration review results is the primary mechanism for making blockchain developer advisory value visible over time. An entry that records the reentrancy vulnerability in the escrow withdrawal function, the attack vector that the vulnerability created, and the checks-effects-interactions fix that was deployed on testnet and validated before the external audit gives the technical lead a concrete example of what the security review function prevents. An entry that records the batch claim gas scaling analysis, the 30M block gas limit ceiling at 14,300 holders at 2,100 gas per eligibility SLOAD, and the Merkle proof redesign that eliminates the batch size constraint allows the founder to understand what the gas optimization function produces.

A retainer dashboard that makes the blockchain developer’s work log visible to the founder or technical lead without requiring the consultant to send a monthly protocol health report converts the work log from a private advisory record into a shared governance artifact. The protocol team that can see the full sprint’s security reviews, gas optimization analyses, tokenomics modeling sessions, wallet integration reviews, and DeFi protocol design sessions in a single URL understands immediately what the blockchain developer retainer is producing — and has a concrete record to reference when preparing for an external security audit, making retainer renewal decisions, or explaining to investors why the protocol has operated without exploit events since launch.

Frequently asked questions

What does a blockchain developer on retainer typically do?

A blockchain developer or smart contract consultant on monthly retainer typically provides smart contract security review (reentrancy, integer arithmetic, access control, oracle manipulation, front-running vulnerability patterns); gas optimization advisory (storage access pattern review, slot packing, calldata vs. memory parameter analysis, block gas limit scaling analysis); tokenomics design consultation (supply schedule modeling, cliff and linear vest impact analysis, emission rate calibration, governance token design); wallet integration advisory (EIP-4361 Sign-In with Ethereum implementation, WalletConnect v2 integration, multi-signature treasury architecture, ERC-4337 account abstraction evaluation); and DeFi protocol design advisory (AMM invariant review, oracle security architecture, MEV exposure analysis, lending protocol parameter calibration). The mainnet deployment is the visible event; the continuous smart contract governance between deployments is the ongoing retainer function.

What makes smart contract advisory different from regular software advisory?

Smart contracts are immutable after deployment (vulnerabilities cannot be patched without a proxy upgrade or migration), produce irreversible on-chain losses when exploited (stolen tokens cannot be recovered), and are fully transparent (the bytecode is publicly visible to sophisticated attackers). These three properties together make pre-deployment security review the primary value-generating advisory function, rather than the post-deployment debugging and patching cycle that governs conventional software advisory. The advisory retainer is structured around preventing vulnerabilities from being deployed rather than responding to bugs discovered in production.

What blockchain developer retainer work is most commonly underlogged?

Smart contract security reviews that confirmed the contract code was secure against the reviewed vulnerability patterns, gas profile analyses that confirmed all functions were within acceptable cost ranges, tokenomics review sessions that confirmed the economic model parameters were stable, audit preparation sessions that confirmed the codebase was ready for external review, and wallet integration reviews that confirmed the EIP-4361 and WalletConnect implementations were handling edge cases correctly. All represent genuine smart contract governance whose value is in the ongoing confirmation and vulnerability prevention rather than in a finding list.

What should a blockchain developer retainer agreement include?

Repository access scope definition, scope boundary between advisory and implementation work (writing production Solidity code and managing deployment keys are separate from advisory), audit coordination scope definition, a shared work log visible to technical leadership that documents the ongoing security reviews, gas optimization sessions, tokenomics advisory, and DeFi protocol design sessions, and an explicit disclaimer that the advisory retainer is not a substitute for a formal external security audit before mainnet deployment of contracts managing significant TVL.

How should blockchain developer retainer hours be logged?

Log entries should capture the Web3 advisory function (smart contract security review, gas optimization, tokenomics design, wallet integration advisory, DeFi protocol design, audit preparation), the contract or protocol component reviewed, the vulnerability pattern or optimization concern analyzed, and the finding or confirmation. Log every session, including security reviews that confirmed the contract was secure, gas analyses that confirmed costs were within range, and tokenomics reviews that confirmed the economic model was stable. The review that confirmed no issues required the same analysis as the review that identified one; logging only sessions with findings systematically understates the volume of smart contract governance work and misrepresents the retainer’s value to the founders making the renewal decision.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark. No client login required. See how it works →