Skip to main content

​
Token Support

Bridgfy operates with an open token policy, accepting any ERC-20 token not on the platform’s security blacklist. This allows for flexible integration while maintaining safety standards.

​
Open Token Policy

​
Token Acceptance

  • Any ERC-20 token is accepted unless explicitly blacklisted for security reasons
  • No pre-registration required - tokens don’t need to be whitelisted or configured
  • Automatic discovery - the system can handle tokens not in the standard configuration

​
Security Blacklist

Bridgfy maintains a security blacklist to prevent interaction with:
  • Sanctioned tokens
  • Known scam or malicious tokens
  • Tokens flagged by security audits
Important: The blacklist is managed by the Bridgfy platform and is not user-configurable. If a deposit attempt uses a blacklisted token, the execution will fail with status TOKEN_BLACKLISTED.

​
Unknown Token Handling

When a deposit involves a token not in Bridgfy’s standard configuration, the system attempts to discover the token’s metadata automatically.

​
Discovery Process

1. Webhook Metadata
  • First, the system extracts metadata from the webhook payload
  • This includes token symbol, decimals, and contract address
  • Most common tokens are included in webhook data
2. Fallback Methods
  • If webhook metadata is unavailable, on-chain ERC-20 metadata calls are attempted
  • The system queries symbol(), decimals(), and name() functions
  • This works for most standard ERC-20 tokens
3. Default Values
  • If all discovery methods fail, the system uses fallback values:
    • Symbol: "UNKNOWN"
    • Decimals: Best-effort guess based on common patterns

​
Routing Behavior

Unknown tokens can still route if the cross-chain routing provider supports them:
  • Symbol defaults to "UNKNOWN" in logs and execution records
  • Decimals must be resolved (6, 18 most common) or routing fails
  • Execution proceeds normally if a valid route is found
  • If the routing provider doesn’t support the token, execution fails with FAILED_UNROUTABLE_MAIN

​
Example: Unknown Token Flow

Successful routing: 
1. User deposits 0x1234...ABCD (not in standard config)
2. Webhook metadata: { symbol: "NEWCOIN", decimals: 18 }
3. Routing uses address 0x1234...ABCD + symbol "NEWCOIN"
4. Cross-chain quote successful → execution proceeds
5. Metrics labeled: token_symbol="NEWCOIN"
Metadata resolution failure: 
1. User deposits 0x5678...EFGH (not in standard config)
2. Webhook metadata: null
3. On-chain calls timeout or revert
4. Fallback: symbol="UNKNOWN", decimals=18 (assumed)
5. Routing attempts with best-effort metadata
6. If routing provider rejects → FAILED_UNROUTABLE_MAIN

​
Supported Tokens (Standard Configuration)

While Bridgfy accepts any ERC-20 token, the following tokens are in the standard configuration and have optimized support: Base (Chain ID: 8453)
  • ETH (Native)
  • USDC
Ethereum (Chain ID: 1)
  • ETH (Native)
  • USDC
Polygon PoS (Chain ID: 137)
  • MATIC (Native)
  • USDC
Arbitrum One (Chain ID: 42161)
  • ETH (Native)
  • USDC
Avalanche C-Chain (Chain ID: 43114)
  • AVAX (Native)
  • USDC
Tokens in the standard configuration have:
  • Pre-configured metadata (no discovery needed)
  • Optimized routing paths
  • Better monitoring and metrics

​
Routing Provider Support

The ability to route a token depends on whether the cross-chain routing provider supports it:

​
Determining Routability

Use the simulation endpoint to check if a token pair is routable before sending funds: 
POST /api/routing/simulate-deposit
x-api-key: your_api_key
Content-Type: application/json

{
  "userId": "user-123",
  "fromChainId": 8453,
  "fromTokenSymbol": "CUSTOMTOKEN",
  "amountInAtomic": "1000000"
}
If routable: Returns expected output, fees, and route details If not routable: Returns error with status indicating no route found

​
Common Routing Scenarios

Highly Routable Tokens:
  • Major stablecoins (USDC, USDT, DAI)
  • Native gas tokens (ETH, MATIC, AVAX)
  • Popular DeFi tokens (UNI, AAVE, LINK)
May Have Limited Routes:
  • Newly launched tokens
  • Low liquidity tokens
  • Chain-specific tokens
  • Wrapped or derivative tokens
Not Routable:
  • Tokens not supported by any bridge provider
  • Tokens with transfer restrictions
  • Tokens on unsupported chains

​
Best Practices

​
For Token Integration

  1. Test with simulation - Always simulate deposits with new tokens before going live
  2. Monitor executions - Track success rates for different token pairs
  3. Handle failures gracefully - Inform users if a token pair is not routable
  4. Communicate clearly - Let users know which tokens are well-supported

​
Error Handling

When working with less common tokens: FAILED_UNROUTABLE_MAIN
  • No routing path found for the token pair
  • Check if the token is supported by bridge providers
  • Consider using a more common token or different destination chain
TOKEN_BLACKLISTED
  • Token is on the security blacklist
  • This is a terminal error (cannot be retried)
  • Use a different token
FAILED_INSUFFICIENT_AFTER_FEES
  • Deposit amount too small after fees
  • More common with low-liquidity tokens (higher bridge fees)
  • Increase deposit amount or use a different token

​
Testing New Tokens

Before integrating a new or uncommon token:
  1. Use the simulation API to verify routability
  2. Test with small amounts on testnet if available
  3. Monitor execution success rates
  4. Check execution details for fee structures
  5. Verify expected output amounts match reality

​
Limitations

​
What Bridgfy Does NOT Support

  • Non-ERC-20 tokens - Only ERC-20 standard is supported
  • NFTs (ERC-721, ERC-1155) - Not supported
  • Native token transfers to wrong chain - Can’t send ETH to receive MATIC directly
  • Rebasing tokens - Tokens with changing balances may cause issues
  • Fee-on-transfer tokens - Tokens with built-in transfer fees may not route correctly

​
Chain Support

Bridgfy only supports the chains listed in the Introduction section. Tokens on other chains cannot be deposited or routed.

​
Next Steps