SkyeGate

Changelog

1.3.12 – 2026-10-20

• A Solana token can now be named by its mint address in either contract or token. Before, a mint address in token was not used and the gate checked SOL instead. On other chains an address in token now shows the site owner a message pointing to contract, and the gate stays closed until it is moved. Token symbols in token work as before.
• Settings and readme show a Solana token example.

1.3.11 – 2026-10-07

• The membership pass window now opens on skyemeta.com as the Bothy Pass. A member already signed in to their Bothy Pass approves in one tap. Gates, conditions and checks are unchanged.

1.3.10

• Adds “Recognized here”: a gate can now tell visitors what it recognizes, so they know which wallet to bring. Add the new recognized attribute with your own words (for example recognized="Hold 100 USDC") or recognized="auto" for a description built from the condition. The chain name is shown beside it. Gates without the attribute look exactly as before.
• A gate that shows what it recognizes keeps that line on screen after a signed no, and says the wallet does not hold what the gate recognizes. Your own message and fail_message are left as written.
• The attribute only changes what is displayed. The check, and anything already remembered for a visitor, is the same with or without it.
• Updates: the default gate message now says “This content is for holders” where it said “members”. A message you wrote yourself is unchanged.

1.3.9

• Clearer messages at the gate. A visitor is told their wallet does not meet the requirements only when a signed check says so. If a check could not be completed, the gate stays closed, says the wallet could not be checked right now, and offers a Try again button. If the gate’s own setup was declined, the visitor is asked to contact the site owner.
• For administrators: when the verification service declines a gate’s setup, its explanation appears on the gate, visible to administrators only, so a shortcode that needs correcting says what to correct.
• A missing or lapsed ownership signature now says so and lets the visitor sign again.
• Adds XRP Ledger token gates: the new currency attribute names a trust line token’s currency code and is checked and then sent exactly as written (codes are case-sensitive). An XRP Ledger token gate that leaves it out, or carries a code that is not well formed, says so on the page for administrators.
• Adds the optional taxon attribute, a whole number from 0 to 4294967295, which limits an XRP Ledger NFT gate to one collection under an issuer.
• Updates: the readme states SkyeGate Pro’s chain count as 34.

1.3.8

• Post-quantum companion checking strengthened: the companion signature now has to vouch for every claim in the verification it accompanies, where before it was matched on a few. On hosts that can check companions (PHP 8.4+ with OpenSSL 3.5+), a companion that differs from the signed verification in any claim is refused. Nothing changes on other hosts, and there is nothing to configure.
• Updates: token gates no longer send a decimals value. The token’s own decimals are read from the chain, so the decimals attribute is no longer needed. Shortcodes that still carry it keep working.
• Adds Robinhood Chain and Arc.
• Updates: Moonbeam and Moonriver are retired. A gate that names either one stays closed and tells the site administrator why.
• Clarifies: an NFT gate with no collection address now says so on the page for administrators.

1.3.7

• A remembered verification now belongs to the visitor who earned it. A verdict was remembered against the wallet address alone, and an address is public, so someone who knew a member’s address could pick up that member’s access during the cache window without proving the wallet was theirs. The ownership signature is now part of what identifies a remembered verdict, and a check on an EVM wallet that carries no signature is declined by the plugin itself.

1.3.6

• The cache duration setting now explains what it does and what to set it to.

1.3.5

• Access now expires exactly when the check behind it does. A returning visitor refreshed their own access without a new check being made, so access could outlast the check that granted it by up to the cache window. It is now capped by the remaining life of that check.

1.3.4

• EAS attestation gates now work from the shortcode. The template attribute is read as documented.
• Token thresholds are sent as exact decimal strings, matching the current verification contract. Very small and very large thresholds are no longer reshaped in transit.
• Post-quantum companion checking strengthened: a companion is now accepted only from the attestation signing key, and the key named in the response must be the key that actually signed.
• The settings screen reports the outcome of the most recent verification, not just whether this host can check companions.

1.3.3

• Housekeeping: the package no longer includes the build tooling’s dependency lockfile, which WordPress never used. No functional changes.

1.3.2

• Post-quantum companion signatures: InsumerAPI now returns an ML-DSA-65 signature beside the ES256 one. On hosts that can verify it (PHP 8.4+ with OpenSSL 3.5+) the plugin checks it and refuses a companion that fails; on other hosts the ES256 verification stands alone and the settings screen says so. Nothing existing changes.

1.3.1

• Verification now accepts attestations from InsumerAPI’s newer signing keys (key identifier insumer-attest-v2) alongside the original insumer-attest-v1 – required as verification accounts move to the newer keys

1.3.0

• Strengthened wallet verification with an ownership signature: after connecting, the visitor’s wallet approves a quick, free signature (no transaction, nothing to type) proving they control the address – passkey wallets confirm with Face ID or fingerprint
• One signature covers the whole visit – every gate on the page then verifies as usual
• The signature goes straight from the visitor’s browser to the verification service; your site never handles it, and still only ever sees the signed yes-or-no
• Membership pass (email) connections carry the same ownership proof automatically – the pass signs during Approve, nothing extra for the member to do

1.2.0

• New: “Membership pass (email)” on every gate. Visitors whose community pass lives in an email wallet (a SkyeMeta Bothy pass) connect through a secure window on the pass’s own site: they approve once and the gate verifies as usual. No app, no extension, nothing installed
• Clearer gate: “Connect Crypto Wallets” says what it does, the passkey option carries its current Base account name, and each alternative explains who it’s for
• Works alongside every existing wallet connection, nothing changes for MetaMask, Phantom, Coinbase, GemWallet, or Crossmark

1.1.0

• New: Coinbase Smart Wallet (passkey) support. Visitors without a wallet extension can connect with a passkey popup; the Coinbase Wallet SDK ships inside the plugin and loads only when chosen (no CDN)
• Clearer guidance when no browser wallet is detected

1.0.4

• Single-condition gates on 31 blockchains (token balance, NFT ownership, EAS attestation)
• Multi-wallet: MetaMask, Phantom, Coinbase Wallet, and any wallet supporting EIP-6963
• Cryptographically signed verification results (ECDSA + JWKS), verified on the server before content release
• Server-side content delivery: gated HTML is never present in the page source
• Per-visitor session binding so a verification in one browser does not unlock gated content in another
• Built-in caching to minimize verification calls