Observed since 20 Oct, 23:07 UTC
No superseded metadata states collected. Unchanged observations do not create new revisions.
@nfight/signer offers an ethers-based `Signer` for implementing nFight's meta-transaction stack in your dapp.
@nfight/signer offers an ethers-based Signer for implementing nFight's meta-transaction stack in your dapp.
Provide an EssentialSigner to an ethers Contract or wagmi contract hook and user transactions will seamlessly become meta-transactions.
Cross-chain NFT auth: pass an NFT's chainId, contractAddress and tokenId to Contract calls - CCTG authorizes ownership and forwards this data to your L2 contract for building cross-chain experiences without bridging.
Network Agnostic UX: EssentialSigner lets users sign meta-transactions with their Ethereum wallet from any network - no network switching or L2 gas tokens needed.
Burner Wallets: nFight supports localized on-chain delegation for NFT auth. Pass a burner Wallet to EssentialSigner so users sign meta-transactions without a popup, while your L2 contract receives the primary address as the _msgSender().
Simple Integration: EssentialSigner is based on ethers, written in typescript and can be used in testing environments like hardhat.
The package is available via NPM:
yarn install @nfight/signer
The SDK expects you to set some ENV vars in your dApp's environment:
The chain ID value for the chain where your implementation contract lives. 0xEssential currently supports Polygon's Mumbai testnet (80001) and Matic mainnet (137).
The SDK will handle submitting meta-transaction requests to your relayer. To do so the SDK needs to know the URI of the relaying service. This can be a fully qualified URL or a relative path.
nFight provides an OpenZeppelin Defender autotask that can be used as your relayer, but we recommend proxying the call to your autotask webhook to keep the URL secret.
Download counts and popularity will appear here as the collector receives them.
| Version | Published | Direct dependencies | Open version |
|---|---|---|---|
| 0.0.1-beta-38Registry latest | 13 Dec 2022 | 12 | |
| 0.0.1-beta-37 | 19 Oct 2022 | 12 | |
| 0.0.1-beta-36 | 11 Oct 2022 | 12 | |
| 0.0.1-beta-35 | 5 Oct 2022 | 12 | |
| 0.0.1-beta-34 | 29 Sept 2022 | 11 | |
| 0.0.1-beta-33 | 28 Sept 2022 | 11 | |
| 0.0.1-beta-32 | 22 Sept 2022 | 11 | |
| 0.0.1-beta-31 | 22 Sept 2022 | 11 | |
| 0.0.1-beta-30 | 22 Sept 2022 | 11 | |
| 0.0.1-beta-29 | 22 Sept 2022 | 11 | |
| 0.0.1-beta-28 | 22 Sept 2022 | 11 | |
| 0.0.1-beta-27 | 21 Sept 2022 | 11 | |
| 0.0.1-beta-26 | 21 Sept 2022 | 11 | |
| 0.0.1-beta-25 | 20 Sept 2022 | 11 | |
| 0.0.1-beta-24 | 6 Sept 2022 | 11 | |
| 0.0.1-beta-23 | 4 Sept 2022 | 11 | |
| 0.0.1-beta-22 | 4 Sept 2022 | 11 | |
| 0.0.1-beta-21 | 4 Jul 2022 | 11 | |
| 0.0.1-beta-20 | 4 Jul 2022 | 11 | |
| 0.0.1-beta-19 | 4 Jul 2022 | 11 |
This describes our collected data; it is not a security assessment.
Observed since 20 Oct, 23:07 UTC
No superseded metadata states collected. Unchanged observations do not create new revisions.
package:178abf9b96270fafa8451f99dd0ae25d7ce2052f6e368ccb7e49022c88ce4020